Причина найдена: одноимённые колонки в разных списках — разные поля со своими
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 <noreply@anthropic.com>
Проверено на тенанте 2026-08-28, при разборе «перевести отчёт по вакансиям
на Search или нет»:
1. Часть полей индекс не отдаёт ВООБЩЕ, хотя значения в списках есть
(OpenReason/OpenReasonDetails, CandidateName/HireDate/ReplacedEmployee,
Ticket). Рядом в тех же списках PositionOWSTEXT, RequestStatusOWSCHCS,
SelectionRequestIdOWSNMBR и др. отдаются нормально — то есть дело не в
типе колонки и не в задержке crawl. Добавлена таблица с тем, какие имена
уже перепробованы, чтобы не ходить по кругу.
2. Отличить «managed property нет» от «есть, но пусто» через SelectProperties
нельзя — на несуществующее имя молча приходит null. Отличается сортировкой:
SortList по несуществующему свойству падает 400/500.
3. Права у заявок портала разорваны на КАЖДОМ элементе
(HasUniqueRoleAssignments = true), поэтому под своей учёткой в списке видно
2 элемента из 19 — не баг и не кэш браузера. App-only это не трогает.
Отсюда же: ItemCount списка считает всё, /items — только доступное вам.
Заодно исправлено утверждение «Search под app-only обычно ничего не отдаёт» —
на сертификате CN=PnP-SharePoint-Sync отдаёт, и postquery, и кастомные
managed properties.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gorbenko.pavel
gorbenko.pavel