Причина найдена: одноимённые колонки в разных списках — разные поля со своими
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>
Пункт меню виден только заданному списку почт (Тришина, Городецкий,
Горбенко) — группы HR в SharePoint пока нет, добавили TODO завести
проверку по ней отдельно (reportsAccess.ts). Скрыт из меню совсем, а
не показан неактивным, и прямой переход по ?rpnav=reports у остальных
редиректит на «Новую заявку».
Раздел — форма периода (С/По) и кнопка «Скачать xlsx», дергает
GET api/reports/vacancies через тот же AadHttpClient, что и остальные
вызовы approval-route API. Имя файла собирается на фронте по формату
бэкенда (VacancyReportWorkbook.FileName), а не читается из
Content-Disposition — approval-route не объявляет заголовок в
Access-Control-Expose-Headers, браузер бы его не отдал.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Печать доступна только после согласования (Отдел рекрутинга); выбор
организации и логотип-шапка для форм с несколькими юрлицами
- «СЗ на перемещение ТМЦ»: заявителя можно выбрать (подача за другого),
маршрут резолвится на выбранного
- «Реферальная рекомендация»: организация вакансии (мультивыбор) и
подразделение/проект вакансии
- Поле «Подразделение» (справочник) — Vacation, UnpaidLeave, Clearance,
WorkplaceSetup, RecruitingHire, RecruitingSelection, TmcTransfer
- Поле «Проект» — Vacation, UnpaidLeave, Clearance
Обсуждение заявки поверх штатных комментариев SharePoint (PnPjs
item.comments) — без новых колонок и провижининга, права на переписку
раздаёт сам SharePoint по правам на элемент.
Встроено в ApproveFeature и EditFeature (единственные входы в просмотр
заявки для всех типов), поэтому доступно автору, всем согласующим
(включая уже решивших и ещё не дошедших до своего шага) и исполнителям,
а не только текущему шагу маршрута, как DecisionPanel.
Автора комментария всегда ставит реальная учётка — отладочная подмена
личности на запись в SharePoint не влияет, в UI есть предупреждение.
---------
Co-authored-by: gorbenko.pavel <gorbenko.pavel@tansu.kz>
Reviewed-on: http://git.tnsu.kz/timur.gorodetskiy/request-portal/pulls/14
gorbenko.pavel
gorbenko.pavel