From 0701736e2350e3c6ec77a111ec57b40596a95d64 Mon Sep 17 00:00:00 2001 From: "gorbenko.pavel" Date: Fri, 28 Aug 2026 14:22:48 +0500 Subject: [PATCH] =?UTF-8?q?docs(tools/sp):=20=D0=BA=D0=BE=D1=80=D0=BD?= =?UTF-8?q?=D0=B5=D0=B2=D0=B0=D1=8F=20=D0=BF=D1=80=D0=B8=D1=87=D0=B8=D0=BD?= =?UTF-8?q?=D0=B0=20=D0=BD=D0=B5=D0=BF=D1=80=D0=BE=D0=B8=D0=BD=D0=B4=D0=B5?= =?UTF-8?q?=D0=BA=D1=81=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=BD=D1=8B?= =?UTF-8?q?=D1=85=20=D0=BF=D0=BE=D0=BB=D0=B5=D0=B9=20+=20=D0=BF=D1=80?= =?UTF-8?q?=D0=B0=D0=B2=D0=BA=D0=B0=20=D0=BF=D1=80=D0=BE=20SortList?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Причина найдена: одноимённые колонки в разных списках — разные поля со своими crawled property, автосозданное managed property привязано к одному из них. Добавлена таблица, показывающая, что PositionOWSTEXT отдаёт значения в одном списке и молчит в другом, — иначе картина выглядит бессмыслицей. Исправлено неверное утверждение из предыдущего коммита: проверять существование managed property через SortList нельзя. Sortable — независимый от Retrievable флаг, у автосозданных ows_* обычно выключен; SortList падает 400/500 и на заведомо живом PositionOWSTEXT. Рабочий способ — сверка Search с REST, её делает `sp-write props`. Co-Authored-By: Claude Opus 5 --- tools/sp/README.md | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/tools/sp/README.md b/tools/sp/README.md index a9148c1..0277213 100644 --- a/tools/sp/README.md +++ b/tools/sp/README.md @@ -112,14 +112,33 @@ claims-логине частей будет четыре. Разбирать с Отличить «managed property нет вовсе» от «есть, но у строк пусто» через `SelectProperties` НЕЛЬЗЯ — на несуществующее имя ответ молча приходит с `null`. -Отличается сортировкой: `SortList` по несуществующему свойству падает ошибкой -400/500, по существующему — работает. +**И `SortList` для этого не годится тоже**, хотя соблазнительно: `Sortable` — флаг, +независимый от `Retrievable`, и у автосозданных `ows_*` свойств он обычно выключен. +`SortList` падает 400/500 и на заведомо живом `PositionOWSTEXT`, то есть меряет не то. +Рабочий способ — сверять Search с REST на одних и тех же элементах, это делает +`sp-write props` (репозиторий `C:\work\git\tools`). -При этом рядом в тех же списках нормально отдаются `PositionOWSTEXT`, -`RequestStatusOWSCHCS`, `SelectionRequestIdOWSNMBR`, `SelectionRequestListIdOWSTEXT`, -`SubmitDateOWSDATE`, `TansuSiteApproverOWSUSER` — то есть это не про тип колонки и не -про задержку crawl (у свежесозданных элементов рабочие поля появляются, а эти нет). -Из-за этого отчёт по вакансиям в `tnsu-approval-route` остался на items REST по +**Корневая причина (нашлась 2026-08-28): одноимённые колонки в разных списках — это +РАЗНЫЕ поля.** У каждого свой GUID, значит и своё crawled property (`ows_Position`, +`ows_Position1`, …), а автосозданное managed property привязано только к одному из них. +Отсюда картина, которая иначе выглядит бессмыслицей: + +| Managed property | «Заявка на подбор 1 — данные» | «Прием на работу 1 — данные» | +| --- | --- | --- | +| `PositionOWSTEXT` | отдаёт | **молчит** | +| `CandidateNameOWSTEXT` | (колонки нет) | **молчит**, но свойство рабочее в других списках | +| `RequestStatusOWSCHCS` | отдаёт | отдаёт | + +То есть проверять надо не «работает ли свойство», а «работает ли оно **для этого +списка**». `sp-write props` в конце как раз и говорит, рабочее ли свойство где-то ещё +на сайте: если да — колонка этого списка отдельное поле, и в Search Schema нужно +домапить её crawled property к тому же managed property; если нигде — свойства нет и +его надо заводить. + +Полностью отсутствуют в схеме (проверено по всему сайту): `OpenReason`, +`OpenReasonDetails`, `HireDate`. + +Из-за всего этого отчёт по вакансиям в `tnsu-approval-route` остался на items REST по партициям, а не на Search — подробный расчёт в doc-комментарии `VacancyReportService`. **Права разорваны на КАЖДОМ элементе.** У заявок портала