Обходной лист (#7)

Co-authored-by: gorbenko.pavel <gorbenko.pavel@tansu.kz> Reviewed-on: http://git.tnsu.kz/timur.gorodetskiy/request-portal/pulls/7
2026-08-17 05:43:38 +00:00
parent a937e33f2e
commit 364835eaf7
47 changed files with 1962 additions and 359 deletions
@@ -20,7 +20,7 @@ const ApproveFeature: React.FC<IApproveFeatureProps> = ({ context, formKey, item
    <div className={styles.content}>
      {ViewComponent ? (
        <React.Suspense fallback={<div className={styles.state}>Загрузка…</div>}>
-          <ViewComponent context={context} itemId={itemId} />
+          <ViewComponent context={context} itemId={itemId} formKey={formKey} />
        </React.Suspense>
      ) : (
        <div className={styles.state}>Для формы «{formKey}» режим согласования пока не настроен.</div>
@@ -1,3 +1,4 @@
+import { SPFI } from '@pnp/sp';
 import { spForSite } from '../../shared/pnp/pnpjs';
 import '@pnp/sp/webs';
 import '@pnp/sp/lists';
@@ -7,8 +8,10 @@ import '@pnp/sp/site-users/web';
 import '@pnp/sp/search';
 import { WebPartContext } from '@microsoft/sp-webpart-base';
 import { getRequestTypes, IRequestType, REQUEST_STATUS } from '../../shared/approval';
+import { effectiveUserEmail } from '../../shared/impersonation';
 import { IMyRequest } from './models/IMyRequest';
 import { IMyRequestsTypeDebug } from './models/IMyRequestsDebug';
+import { traceLinkedTypes, traceResultRows, traceSearchHits } from './searchTrace';

 // Список данных «... — данные» → список согласования «... — согласование»
 // (конвенция именования; см. forms/*/provisioning.json и forms/*/approval/provisioning.json).
@@ -22,11 +25,24 @@ const DATA_LIST_SUFFIX = /\s*—\s*данные\s*$/;
 // свежесть); при поиске по тексту эта подстраховка не применяется (см. RequestsTableView).
 const RECENT_MS = 10 * 60 * 1000;

-// Сколько строк согласования максимум забираем из Search за один запрос
-// (см. getInvolvedRowsViaSearch). Постраничного перебора здесь нет: набор
-// целиком уходит в слияние и сортировку по дате заявки, поэтому при превышении
-// лимита пишем предупреждение в лог, а не молча обрезаем.
-const SEARCH_ROW_LIMIT = 500;
+// Сколько строк максимум запрашиваем у Search за ОДИН HTTP-вызов — верхняя
+// граница RowLimit самого SharePoint Search REST API. Полный набор всегда
+// собирается несколькими такими вызовами через StartRow (см.
+// fetchAllSearchRows) — это не потолок итогового результата.
+const SEARCH_PAGE_SIZE = 500;
+
+// Абсолютный потолок на суммарное число строк, которые fetchAllSearchRows
+// заберёт за все страницы, — защита от зависания на аномально большом
+// индексе, а не ожидаемый рабочий предел. При достижении пишем предупреждение
+// и возвращаем то, что успели собрать, вместо бесконечного перебора.
+const SEARCH_HARD_CAP = 5000;
+
+// Сколько Id максимум перечисляем в одном REST $filter (`Id eq 1 or Id eq 2…`)
+// при дочитывании полей по найденным через Search элементам (см. loadByIds).
+// SharePoint REST не резиновый по длине URL — несколько сотен ИЛИ уже рискуют
+// упереться в лимит, поэтому набор Id одного типа режется на такие пачки,
+// а не уходит одним запросом целиком.
+const REST_ID_FILTER_CHUNK = 100;

 // Сколько последних заявок автора дочитываем через REST в довесок к Search
 // в разделе «Мои заявки» (см. getFreshOwnRowsForType). Это записи ОДНОГО
@@ -41,26 +57,35 @@ const MP_APPROVER = 'TansuSiteApproverOWSUSER';
 // Статус СТРОКИ МАРШРУТА (колонка ApprovalStatus списка «— согласование») —
 // Choice-поле, отсюда суффикс OWSCHCS (подтверждено отладочным перебором
 // 2026-08-06; у Person-полей он OWSUSER, см. MP_APPROVER). Колонку не путать с
-// RequestStatus списка ДАННЫХ — это статус ЗАЯВКИ целиком.
-//
-// Для статуса ЗАЯВКИ (список ДАННЫХ) отдельной managed property здесь
-// НАМЕРЕННО нет: имя для произвольной Choice-колонки в схеме поиска либо надо
-// знать точно, либо угадывать по конвенции — угадали неверно (или колонка
-// после переименования Status → RequestStatus ещё не переиндексирована), и
-// фильтр по статусу молча возвращал 0 заявок. Поэтому статус заявки
-// фильтруется НЕ в KQL, а в памяти после дочитывания реальных полей через REST
-// (см. getOwnRequestsByStatus) — Search там ищет только по надёжному
-// AuthorOWSUSER, статус ни при чём.
+// RequestStatus списка ДАННЫХ — это статус ЗАЯВКИ целиком (см. MP_REQUEST_STATUS
+// ниже).
 const MP_STATUS = 'ApprovalStatusOWSCHCS';

+// Статус ЗАЯВКИ (колонка RequestStatus списка ДАННЫХ) — Choice-поле, тот же
+// суффикс OWSCHCS, без префикса группы колонок сайта (поле локальное для
+// списка, как и ApprovalStatus выше). Раньше здесь стояло «угадали неверно,
+// фильтр молча возвращает 0» — перепроверено вручную через
+// /_api/search/query 2026-08-17: и голый запрос по этому свойству, и в
+// связке с Path, отдают счётчики, совпадающие с REST-эталоном (см.
+// getOwnRequestsByStatus). Старый вывод о поломке был артефактом кривого
+// тестового Path (задвоенный сегмент /sites/…), а не реальным ограничением
+// SharePoint — сама схема поиска исправна.
+const MP_REQUEST_STATUS = 'RequestStatusOWSCHCS';
+
+// effectiveUserEmail, а не pageContext напрямую: при отладочной подмене личности
+// (см. shared/impersonation.ts) «мои заявки» и очереди согласования должны
+// отбираться по подменённому сотруднику — иначе подмена показывала бы чужой
+// маршрут в форме, но собственные списки заявок.
 export function currentUserEmail(context: WebPartContext): string {
-  return (context.pageContext.user.email || '').toLowerCase();
+  return effectiveUserEmail(context).toLowerCase();
 }

 // Типы заявок, у которых approval-route API уже отдал listId/siteUrl (готовы к чтению).
 export async function getLinkedTypes(context: WebPartContext): Promise<IRequestType[]> {
  const types = await getRequestTypes(context);
-  return types.filter((t) => !!t.listId && !!t.siteUrl);
+  const linked = types.filter((t) => !!t.listId && !!t.siteUrl);
+  traceLinkedTypes(types, linked);
+  return linked;
 }

 // Что показывать в разделе «На согласовании»:
@@ -269,12 +294,12 @@ async function indexApprovalsForType(
    // SharePoint REST — резолвим email в числовой Id пользователя (как и везде в
    // проекте, см. ensureUser) и фильтруем по TansuSiteApproverId.
    //
-    // ApprovalStatus в $filter НЕ используем: подтверждено на практике — фильтр
-    // вида `ApprovalStatus eq 'На согласовании'` (кириллица в $filter) молча
-    // возвращает 0 строк, даже когда без него те же строки находятся с этим же
-    // значением статуса. Поэтому фильтруем только по TansuSiteApproverId
-    // (числовое значение, проблем нет), а статус сравниваем в JS после
-    // получения строк.
+    // ApprovalStatus в $filter теперь ИСПОЛЬЗУЕМ: раньше здесь считалось, что
+    // кириллица в значении делает такой фильтр ненадёжным, — перепроверено
+    // вручную через REST 2026-08-17 (все три статуса списка согласования дали
+    // точное совпадение с эталоном), теория не подтвердилась. Старый вывод о
+    // поломке был артефактом кривого тестового запроса, а не реальным
+    // ограничением SharePoint.
    const claimsLogin = tokenEmail.indexOf('|') >= 0 ? tokenEmail : `i:0#.f|membership|${tokenEmail}`;
    const approver = await sp.web.ensureUser(claimsLogin);

@@ -289,20 +314,20 @@ async function indexApprovalsForType(
      // getInvolvedRowsViaSearch, поэтому решение «моя очередь сейчас» всегда
      // точное, даже когда список кандидатов пришёл из Search.
      const cutoffIso = new Date(Date.now() - RECENT_MS).toISOString();
+      // Статус — прямо в $filter (см. комментарий про ApprovalStatus выше):
+      // REST-довесок сразу отдаёт только нужные строки, без постфильтрации в JS.
+      const statusFilter =
+        statuses.length > 0 ? ` and (${statuses.map((s) => `ApprovalStatus eq '${s}'`).join(' or ')})` : '';
      const recentRows = (await approvalList.items
-        .filter(`TansuSiteApproverId eq ${approver.Id} and Modified ge '${cutoffIso}'`)
+        .filter(`TansuSiteApproverId eq ${approver.Id} and Modified ge '${cutoffIso}'${statusFilter}`)
        .select('Id', 'TicketId', 'ApprovalStatus')
        .top(2000)()) as Array<Record<string, unknown>>;

-      // Статусы уходят в KQL: сервер сразу отдаёт только нужные строки,
+      // Статусы уходят и в KQL: сервер сразу отдаёт только нужные строки,
      // а не всё, где пользователь есть в маршруте.
      const searchRows = await getInvolvedRowsViaSearch(context, type, approvalList, statuses);
      const seenIds = new Set(recentRows.map((r) => r.Id));
-      const allRows = recentRows.concat(searchRows.filter((r) => !seenIds.has(r.Id)));
-
-      // REST-довесок берётся по Modified без учёта статуса (кириллица в $filter
-      // ненадёжна, см. выше) — отбор по статусу делаем здесь, на клиенте.
-      stepRows = allRows.filter((r) => statuses.indexOf(r.ApprovalStatus as string) !== -1);
+      stepRows = recentRows.concat(searchRows.filter((r) => !seenIds.has(r.Id)));
    } else {
      // 'involved' — используется ТОЛЬКО для текстового поиска (см.
      // getPendingApprovalIndex/searchMyRequests) — здесь важна не мгновенная
@@ -401,7 +426,9 @@ async function getInvolvedRowsViaSearch(
      .expand('RootFolder')()) as { RootFolder?: { ServerRelativeUrl?: string } };
    const relUrl = rootFolder.RootFolder?.ServerRelativeUrl;
    if (!relUrl) return [];
-    const approvalListAbsUrl = `${siteOrigin(type.siteUrl as string)}${relUrl}`;
+    // Слеш на конце обязателен: без него префикс …/Lists/List1 совпадает и с
+    // путями элементов …/Lists/List10 (см. listPathPrefix).
+    const approvalListAbsUrl = `${siteOrigin(type.siteUrl as string)}${relUrl.replace(/\/+$/, '')}/`;

    const sp = spForSite(type.siteUrl as string, context);
    const pathClause = `Path:"${approvalListAbsUrl}*"`;
@@ -411,29 +438,24 @@ async function getInvolvedRowsViaSearch(
    }
    const kql = clauses.join(' AND ');

-    const results = await sp.search({
-      Querytext: kql,
-      RowLimit: SEARCH_ROW_LIMIT,
-      SelectProperties: ['ListItemID'],
-      TrimDuplicates: false,
-    });
-
-    const total = results.TotalRows || 0;
-    const ids = (results.PrimarySearchResults as Array<Record<string, unknown>>)
+    const hits = await fetchAllSearchRows(sp, kql, ['ListItemID'], `«${type.name}»`);
+    const ids = hits
      .map((r) => Number(r.ListItemID))
      .filter((id) => !isNaN(id) && id > 0);

-    if (total > SEARCH_ROW_LIMIT) {
-      console.warn(
-        `[Текущие заявки] «${type.name}»: Search вернул ${total} строк, взяли первые ${SEARCH_ROW_LIMIT} — остальные не попадут в выборку`
-      );
-    }
    if (ids.length === 0) return [];

-    return (await approvalList.items
-      .filter(ids.map((id) => `Id eq ${id}`).join(' or '))
-      .select('Id', 'TicketId', 'ApprovalStatus')
-      .top(ids.length)()) as Array<Record<string, unknown>>;
+    // Id режем на пачки — тот же предел длины URL REST $filter, что и в
+    // loadByIds (см. REST_ID_FILTER_CHUNK).
+    const chunks = await Promise.all(
+      chunk(ids, REST_ID_FILTER_CHUNK).map((idsChunk) =>
+        approvalList.items
+          .filter(idsChunk.map((id) => `Id eq ${id}`).join(' or '))
+          .select('Id', 'TicketId', 'ApprovalStatus')
+          .top(idsChunk.length)()
+      )
+    );
+    return (chunks as Array<Array<Record<string, unknown>>>).reduce((all, r) => all.concat(r), []);
  } catch (e) {
    console.error(
      `[Текущие заявки] «${type.name}»: Search по списку согласования не сработал:`,
@@ -508,10 +530,64 @@ export interface IOwnRequestsPage {
 }

 const PAGE_SIZE = 20;
-// Сколько заявок максимум перечисляем в KQL при поиске среди уже отобранных
-// (см. filterPendingByQuery) — иначе строка запроса станет неподъёмной.
+// Сколько заявок-кандидатов максимум перечисляем в ОДНОМ KQL-запросе при
+// поиске среди уже отобранных (см. filterPendingByQuery) — не потолок
+// итогового результата, а размер чанка: кандидатов режем на такие пачки и
+// прогоняем каждую отдельным запросом, чтобы строка запроса не разрослась
+// до неподъёмной, но при этом ни один кандидат не терялся.
 const KQL_ID_LIMIT = 300;

+function chunk<T>(items: T[], size: number): T[][] {
+  const result: T[][] = [];
+  for (let i = 0; i < items.length; i += size) {
+    result.push(items.slice(i, i + size));
+  }
+  return result;
+}
+
+// Собрать ВЕСЬ результат Search по запросу, а не одну страницу: сам
+// SharePoint Search REST API ограничивает RowLimit одного вызова (см.
+// SEARCH_PAGE_SIZE), поэтому при большом совпадающем наборе перебираем
+// StartRow, пока индекс не перестанет отдавать новые строки или пока не
+// упрёмся в SEARCH_HARD_CAP (аварийный потолок, а не ожидаемый лимит — при
+// его достижении пишем предупреждение и отдаём то, что успели собрать).
+async function fetchAllSearchRows(
+  sp: SPFI,
+  kql: string,
+  selectProperties: string[],
+  label: string,
+  sortList?: Array<{ Property: string; Direction: number }>
+): Promise<Array<Record<string, unknown>>> {
+  const rows: Array<Record<string, unknown>> = [];
+  let startRow = 0;
+
+  for (;;) {
+    const results = await sp.search({
+      Querytext: kql,
+      RowLimit: SEARCH_PAGE_SIZE,
+      StartRow: startRow,
+      SelectProperties: selectProperties,
+      TrimDuplicates: false,
+      ...(sortList ? { SortList: sortList } : {}),
+    });
+
+    const page = results.PrimarySearchResults as Array<Record<string, unknown>>;
+    rows.push(...page);
+    const total = results.TotalRows || 0;
+    startRow += page.length;
+
+    if (page.length === 0 || startRow >= total) break;
+    if (rows.length >= SEARCH_HARD_CAP) {
+      console.warn(
+        `[Текущие заявки] ${label}: индекс отдал ${total} строк — забрали только первые ${rows.length} (аварийный потолок)`
+      );
+      break;
+    }
+  }
+
+  return rows;
+}
+
 function siteOrigin(siteUrl: string): string {
  const match = /^https?:\/\/[^/]+/.exec(siteUrl);
  return match ? match[0] : siteUrl;
@@ -521,6 +597,24 @@ function listAbsUrl(type: IRequestType): string {
  return `${siteOrigin(type.siteUrl as string)}${type.listId}`;
 }

+// Префикс пути для KQL-условия Path и для сопоставления хитов с типом.
+//
+// Обязательно СО слешем на конце: адреса списков в этом сайте отличаются только
+// номером (…/Lists/List1, …/Lists/List10), и «голый» префикс List1 совпадает с
+// путями элементов List10. В KQL это притягивало чужие элементы, а при разборе
+// ответа хит уезжал в первый подошедший тип — заявки «Обходного листа»
+// приписывались списку List1, дальше их Id искались не в том списке и строки
+// молча исчезали из выдачи.
+function listPathPrefix(type: IRequestType): string {
+  return `${listAbsUrl(type).replace(/\/+$/, '')}/`;
+}
+
+// Хит принадлежит типу, только если путь элемента лежит ВНУТРИ списка —
+// сравнение по границе сегмента, не по «голому» началу строки.
+export function pathBelongsToList(path: string, type: IRequestType): boolean {
+  return path.toLowerCase().indexOf(listPathPrefix(type).toLowerCase()) === 0;
+}
+
 // KQL не терпит спецсимволов в свободном терме — оставляем буквы (лат./кир.),
 // цифры и пробелы. (без \p{L} — целевой ES-таргет проекта его не поддерживает)
 function sanitizeForKql(text: string): string {
@@ -542,23 +636,26 @@ function freeTextClause(query: string): string | undefined {
 //
 // Дедуп по (тип, Id) — ЗДЕСЬ, а не у вызывающей стороны: во всех запросах
 // стоит TrimDuplicates: false (нужно, чтобы найти черновики и «свои» копии —
-// стандартная дедупликация Search иногда схлопывает и их), а без неё индекс
-// может вернуть один и тот же элемент несколькими хитами (переиндексация,
-// несколько «версий» в crawl). Раньше хиты превращались в строки один-в-один,
-// и дубликат из индекса становился дубликатом строки в таблице — с одинаковым
-// React-ключом, то есть видимым «залипанием» одной и той же заявки дважды.
+// стандартная дедупликация Search схлопывает по содержимому, а не по Id, и
+// вместе с ними может случайно схлопнуть две по-настоящему разные, но похожие
+// заявки), а без неё индекс может вернуть один и тот же элемент несколькими
+// хитами (переиндексация, несколько «версий» в crawl). Раньше хиты
+// превращались в строки один-в-один, и дубликат из индекса становился
+// дубликатом строки в таблице — с одинаковым React-ключом, то есть видимым
+// «залипанием» одной и той же заявки дважды.
 function hitsToEntries(
  results: { PrimarySearchResults: unknown[] },
  types: IRequestType[]
 ): Array<{ id: number; type: IRequestType }> {
-  const urls = types.map((t) => ({ type: t, url: listAbsUrl(t).toLowerCase() }));
  const seen = new Set<string>();
  return (results.PrimarySearchResults as Array<Record<string, unknown>>)
-    .map((r) => ({ id: Number(r.ListItemID), path: String(r.Path || '').toLowerCase() }))
+    .map((r) => ({ id: Number(r.ListItemID), path: String(r.Path || '') }))
    .filter((h) => !isNaN(h.id) && h.id > 0)
    .map((h) => {
-      const matched = urls.filter((u) => h.path.indexOf(u.url) === 0)[0];
-      return matched ? { id: h.id, type: matched.type } : undefined;
+      // Сравнение по границе сегмента (см. listPathPrefix): при «голом»
+      // indexOf хиты List10 доставались типу List1 — тому, что раньше в массиве.
+      const matched = types.filter((t) => pathBelongsToList(h.path, t))[0];
+      return matched ? { id: h.id, type: matched } : undefined;
    })
    .filter((e): e is { id: number; type: IRequestType } => !!e)
    .filter((e) => {
@@ -571,6 +668,11 @@ function hitsToEntries(

 // Дочитать поля заявок по найденным Id (Search отдаёт не все колонки, и для
 // кастомных полей нет гарантии, что они проиндексированы как managed property).
+//
+// Id одного типа режем на пачки REST_ID_FILTER_CHUNK: теперь, когда Search
+// собирает результат целиком (см. fetchAllSearchRows), их может набраться
+// заметно больше сотни — один $filter из тысяч «Id eq N or …» упёрся бы в
+// предел длины URL SharePoint REST.
 async function loadByIds(
  context: WebPartContext,
  entries: Array<{ id: number; type: IRequestType }>,
@@ -587,16 +689,21 @@ async function loadByIds(
  await Promise.all(
    Array.from(idsByType.entries()).map(async ([type, ids]) => {
      const sp = spForSite(type.siteUrl as string, context);
-      const rows = (await sp.web
-        .getList(type.listId as string)
-        .items.filter(ids.map((id) => `Id eq ${id}`).join(' or '))
-        .select('Id', 'Title', 'RequestStatus', 'Created', 'Author/EMail', 'Author/Title')
-        .expand('Author')
-        .top(ids.length)()) as Array<Record<string, unknown>>;
-      rows.forEach((r) => {
-        const author = r.Author as { EMail?: string; Title?: string } | undefined;
-        byKey.set(`${type.id}-${r.Id as number}`, toMyRequest(r, author, type, kind));
-      });
+      const list = sp.web.getList(type.listId as string);
+
+      await Promise.all(
+        chunk(ids, REST_ID_FILTER_CHUNK).map(async (idsChunk) => {
+          const rows = (await list.items
+            .filter(idsChunk.map((id) => `Id eq ${id}`).join(' or '))
+            .select('Id', 'Title', 'RequestStatus', 'Created', 'Author/EMail', 'Author/Title')
+            .expand('Author')
+            .top(idsChunk.length)()) as Array<Record<string, unknown>>;
+          rows.forEach((r) => {
+            const author = r.Author as { EMail?: string; Title?: string } | undefined;
+            byKey.set(`${type.id}-${r.Id as number}`, toMyRequest(r, author, type, kind));
+          });
+        })
+      );
    })
  );
  return byKey;
@@ -604,9 +711,8 @@ async function loadByIds(

 // Последние OWN_REST_TOP заявок автора одного типа обычным REST-ом, в обход
 // Search — сырьё для довеска по свежести (см. getFreshOwnRowsForType).
-// Фильтруем только по AuthorId: статус в $filter не используем, потому что
-// кириллица в сравнении там уже подводила (см. indexApprovalsForType) — отбор
-// по статусу делает вызывающая сторона.
+// Фильтруем только по AuthorId, без статуса: эта функция возвращает ВСЕ
+// заявки автора, отбор по статусу (если он нужен) делает вызывающая сторона.
 async function getOwnRowsForType(context: WebPartContext, type: IRequestType): Promise<IMyRequest[]> {
  try {
    const sp = spForSite(type.siteUrl as string, context);
@@ -728,7 +834,7 @@ export async function searchOwnRequests(
  const claimsLogin = `i:0#.f|membership|${currentUserEmail(context)}`;

  const clauses = [
-    `(${types.map((t) => `Path:"${listAbsUrl(t)}*"`).join(' OR ')})`,
+    `(${types.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`,
    `AuthorOWSUSER:"${claimsLogin}"`,
  ];
  const text = freeTextClause(query);
@@ -758,17 +864,10 @@ export async function searchOwnRequests(
 // Свои заявки с конкретным статусом ЗАЯВКИ (не строки маршрута) — «Доработка»
 // и фильтр по статусу на вкладке «Инициированные».
 //
-// Статус НЕ уходит в KQL: единственная надёжная managed property здесь —
-// AuthorOWSUSER (стандартное поле автора), а для произвольной Choice-колонки
-// имя managed property надо либо знать из схемы поиска, либо угадывать по
-// конвенции — угадали неверно (или она ещё не переиндексирована после
-// переименования колонки Status → RequestStatus), из-за чего фильтр по
-// статусу молча возвращал 0. Поэтому здесь Search ищет ТОЛЬКО по автору
-// (+ опционально текст) — это находит ВСЕ заявки автора вплоть до
-// KQL_ID_LIMIT, — а отбор по статусу и постраничность делаются в памяти по
-// уже дочитанным через REST реальным полям (см. searchOwnAll/loadByIds).
-// Тот же принцип, что и в filterPendingByQuery: Search сужает набор по
-// надёжному полю, остальное — на клиенте.
+// Статус уходит прямо в KQL через MP_REQUEST_STATUS (проверено вручную
+// 2026-08-17, см. комментарий у константы) — это настоящий серверный запрос
+// с RowLimit/StartRow, как и searchOwnRequests, а не «стянуть всё и
+// отфильтровать в памяти».
 export async function getOwnRequestsByStatus(
  context: WebPartContext,
  types: IRequestType[],
@@ -776,28 +875,52 @@ export async function getOwnRequestsByStatus(
  page: number,
  query: string = ''
 ): Promise<IOwnRequestsPage> {
-  const all = await searchOwnAll(context, types, query);
-  const searchFiltered = all.filter((r) => r.status === status);
+  if (types.length === 0) return { rows: [], totalRows: 0 };
+
+  const sp = spForSite(types[0].siteUrl as string, context);
+  const claimsLogin = `i:0#.f|membership|${currentUserEmail(context)}`;
+  const clauses = [
+    `(${types.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`,
+    `AuthorOWSUSER:"${claimsLogin}"`,
+    `${MP_REQUEST_STATUS}:"${status}"`,
+  ];
+  const text = freeTextClause(query);
+  if (text) clauses.push(text);
+  const kql = clauses.join(' AND ');
+
+  const results = await sp.search({
+    Querytext: kql,
+    RowLimit: PAGE_SIZE,
+    StartRow: (page - 1) * PAGE_SIZE,
+    SelectProperties: ['ListItemID', 'Title', 'Path'],
+    TrimDuplicates: false,
+    // Свежие сверху — как в searchOwnRequests.
+    SortList: [{ Property: 'Created', Direction: 1 }],
+  });
+
+  const totalRows = results.TotalRows || 0;
+  const entries = hitsToEntries(results, types);
+  const byKey = entries.length > 0 ? await loadByIds(context, entries, 'own') : new Map<string, IMyRequest>();
+  const searchRows = entries.map((e) => byKey.get(`${e.type.id}-${e.id}`)).filter((r): r is IMyRequest => !!r);
+
+  if (page !== 1 || query.trim()) return { rows: searchRows, totalRows };

  // Довесок по недавним изменениям — только на первой странице и только без
-  // текстового поиска (см. getOwnRequests: тот же принцип — довесок относится
-  // к «показать всё, свежее по дате», а не к результату полнотекстового поиска).
-  let merged = searchFiltered;
-  if (page === 1 && !query.trim()) {
-    const freshRows = (await Promise.all(types.map((t) => getRecentlyChangedOwnRowsForType(context, t))))
-      .reduce((acc, r) => acc.concat(r), [] as IMyRequest[])
-      .filter((r) => r.status === status);
+  // текстового поиска (тот же принцип, что в getOwnRequests): заявку могли
+  // вернуть на доработку только что, индекс мог не успеть её подхватить.
+  const freshRows = (await Promise.all(types.map((t) => getRecentlyChangedOwnRowsForType(context, t))))
+    .reduce((acc, r) => acc.concat(r), [] as IMyRequest[])
+    .filter((r) => r.status === status);

-    const seen = new Set(searchFiltered.map((r) => `${r.requestTypeId}-${r.id}`));
-    const onlyFresh = freshRows.filter((r) => !seen.has(`${r.requestTypeId}-${r.id}`));
-    merged = onlyFresh.concat(searchFiltered);
-  }
+  const searchKeys = new Set(searchRows.map((r) => `${r.requestTypeId}-${r.id}`));
+  const onlyFresh = freshRows.filter((r) => !searchKeys.has(`${r.requestTypeId}-${r.id}`));

-  const sorted = merged.sort((a, b) => b.created.localeCompare(a.created));
-  return {
-    rows: sorted.slice((page - 1) * PAGE_SIZE, page * PAGE_SIZE),
-    totalRows: sorted.length,
-  };
+  const merged = onlyFresh
+    .concat(searchRows)
+    .sort((a, b) => b.created.localeCompare(a.created))
+    .slice(0, PAGE_SIZE);
+
+  return { rows: merged, totalRows: totalRows + onlyFresh.length };
 }

 // Список согласования по типу заявки: Title списка данных → Title списка
@@ -860,17 +983,17 @@ export async function hydrateDecisionComments(
        const approvalList = await approvalListFor(context, type);
        if (!approvalList) return;

-        // Фильтруем только по TicketId (числовое поле), статус сравниваем в JS:
-        // кириллица в $filter по Choice-колонке молча возвращает 0 строк —
-        // ровно та же причина, что и в indexApprovalsForType.
+        // TicketId (OR-цепочка) в скобках обязателен: у OData `and` связывает
+        // сильнее `or», без скобок фильтр разобрался бы как
+        // «TicketId eq 1 or (TicketId eq 2 and ApprovalStatus eq …)».
+        const ticketFilter = typeRows.map((r) => `TicketId eq ${r.id}`).join(' or ');
        const stepRows = (await approvalList.items
-          .filter(typeRows.map((r) => `TicketId eq ${r.id}`).join(' or '))
-          .select('TicketId', 'ApprovalStatus', 'Comment')
+          .filter(`(${ticketFilter}) and ApprovalStatus eq '${decisionStatus}'`)
+          .select('TicketId', 'Comment')
          .top(DECISION_COMMENT_ROW_LIMIT)()) as Array<Record<string, unknown>>;

        const commentByTicket = new Map<number, string>();
        stepRows.forEach((r) => {
-          if (r.ApprovalStatus !== decisionStatus) return;
          const ticketId = r.TicketId as number | undefined;
          const comment = ((r.Comment as string) || '').trim();
          // Такая строка по заявке одна (и возврат, и отклонение останавливают
@@ -900,6 +1023,11 @@ export async function hydrateDecisionComments(
 // обычным REST). Здесь среди НИХ фильтруем по тексту — только через Search
 // (KQL ограничивается ListItemID этих заявок, текст идёт свободным термом по
 // всем полям), без клиентского REST-матчинга по свежести.
+//
+// Кандидатов режем на чанки по KQL_ID_LIMIT и гоняем каждый отдельным
+// запросом (см. chunk/fetchAllSearchRows) — раньше «лишние» сверх лимита
+// кандидаты молча выпадали из поиска, теперь ни один не теряется, просто
+// уходит несколькими запросами вместо одного.
 export async function filterPendingByQuery(
  context: WebPartContext,
  types: IRequestType[],
@@ -909,34 +1037,35 @@ export async function filterPendingByQuery(
  const text = freeTextClause(query);
  if (!text || rows.length === 0) return rows;

-  if (rows.length > KQL_ID_LIMIT) {
-    console.warn(
-      `[Текущие заявки] Поиск среди ждущих решения ограничен ${KQL_ID_LIMIT} заявками из ${rows.length}`
-    );
-  }
-  const candidates = rows.slice(0, KQL_ID_LIMIT);
-
-  const scopeTypes = types.filter((t) => candidates.some((r) => r.requestTypeId === t.id));
+  const scopeTypes = types.filter((t) => rows.some((r) => r.requestTypeId === t.id));
  if (scopeTypes.length === 0) return [];

  const sp = spForSite(scopeTypes[0].siteUrl as string, context);
-  const kql = [
-    `(${scopeTypes.map((t) => `Path:"${listAbsUrl(t)}*"`).join(' OR ')})`,
-    `(${candidates.map((r) => `ListItemID:${r.id}`).join(' OR ')})`,
-    text,
-  ].join(' AND ');
+  const pathClause = `(${scopeTypes.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`;

-  const results = await sp.search({
-    Querytext: kql,
-    RowLimit: KQL_ID_LIMIT,
-    SelectProperties: ['ListItemID', 'Title', 'Path'],
-    TrimDuplicates: false,
-  });
+  const found = new Set<string>();
+  await Promise.all(
+    chunk(rows, KQL_ID_LIMIT).map(async (candidates) => {
+      const kql = [
+        pathClause,
+        `(${candidates.map((r) => `ListItemID:${r.id}`).join(' OR ')})`,
+        text,
+      ].join(' AND ');

+      const hits = await fetchAllSearchRows(
+        sp,
+        kql,
+        ['ListItemID', 'Title', 'Path'],
+        'Поиск среди ждущих решения'
+      );
+      // ListItemID уникален только внутри своего списка — сверяем пару тип+Id.
+      hitsToEntries({ PrimarySearchResults: hits }, scopeTypes).forEach((e) =>
+        found.add(`${e.type.id}-${e.id}`)
+      );
+    })
+  );

-  // ListItemID уникален только внутри своего списка — сверяем пару тип+Id.
-  const found = new Set(hitsToEntries(results, scopeTypes).map((e) => `${e.type.id}-${e.id}`));
-  return candidates.filter((r) => found.has(`${r.requestTypeId}-${r.id}`));
+  return rows.filter((r) => found.has(`${r.requestTypeId}-${r.id}`));
 }

 // ---------------------------------------------------------------------------
@@ -956,8 +1085,10 @@ export interface ISearchPage {
  totalRows: number;
 }

-// Как searchOwnRequests, но без $skip/$top — сразу весь найденный срез (до
-// KQL_ID_LIMIT). Только Search, без REST-подстраховки на свежесть.
+// Как searchOwnRequests, но без $skip/$top — сразу весь найденный срез
+// (см. fetchAllSearchRows — весь, а не первые KQL_ID_LIMIT: тот лимит здесь
+// больше не действует, это чанк-размер для другой функции, filterPendingByQuery).
+// Только Search, без REST-подстраховки на свежесть.
 export async function searchOwnAll(
  context: WebPartContext,
  types: IRequestType[],
@@ -968,24 +1099,25 @@ export async function searchOwnAll(
  const sp = spForSite(types[0].siteUrl as string, context);
  const claimsLogin = `i:0#.f|membership|${currentUserEmail(context)}`;
  const clauses = [
-    `(${types.map((t) => `Path:"${listAbsUrl(t)}*"`).join(' OR ')})`,
+    `(${types.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`,
    `AuthorOWSUSER:"${claimsLogin}"`,
  ];
  const text = freeTextClause(query);
  if (text) clauses.push(text);
  const kql = clauses.join(' AND ');

-  const results = await sp.search({
-    Querytext: kql,
-    RowLimit: KQL_ID_LIMIT,
-    SelectProperties: ['ListItemID', 'Title', 'Path'],
-    TrimDuplicates: false,
-  });
+  const hits = await fetchAllSearchRows(sp, kql, ['ListItemID', 'Title', 'Path'], 'Свои заявки');
+  const results = { PrimarySearchResults: hits, TotalRows: hits.length };


+  traceSearchHits('Свои заявки', kql, types, results, listAbsUrl);
+
  const entries = hitsToEntries(results, types);
  const byKey = entries.length > 0 ? await loadByIds(context, entries, 'own') : new Map<string, IMyRequest>();
-  return entries.map((e) => byKey.get(`${e.type.id}-${e.id}`)).filter((r): r is IMyRequest => !!r);
+  const rows = entries.map((e) => byKey.get(`${e.type.id}-${e.id}`)).filter((r): r is IMyRequest => !!r);
+
+  traceResultRows('Свои заявки', types, entries, rows);
+  return rows;
 }

 /**
@@ -0,0 +1,167 @@
+import { IRequestType } from '../../shared/approval';
+
+/**
+ * Точечная отладка поиска по ОДНОМУ типу заявки.
+ *
+ * Зачем отдельный модуль: тип может выпасть из выдачи на любом из пяти шагов
+ * (не пришёл из API маршрутов → не попал в KQL → индекс его не отдал → Path
+ * хита не совпал с адресом списка → REST не вернул строку), и снаружи все пять
+ * выглядят одинаково — «заявок этого типа нет». Трассировка печатает каждый
+ * шаг отдельно, чтобы было видно, на каком именно набор становится пустым.
+ *
+ * Включение/выключение БЕЗ пересборки — из консоли браузера:
+ *   window.rpSearchTrace = 'обходной'  // подстрока имени типа или ключа формы
+ *   window.rpSearchTrace = true        // следить за всеми типами
+ *   window.rpSearchTrace = false       // выключить
+ * Значение сверяется с именем типа и с pageUrl (ключом формы), регистр не важен.
+ */
+const DEFAULT_TRACE: string | boolean = 'обходной';
+
+const PREFIX = '[Поиск]';
+
+function traceSetting(): string | boolean {
+  const w = window as unknown as { rpSearchTrace?: string | boolean };
+  return w.rpSearchTrace === undefined ? DEFAULT_TRACE : w.rpSearchTrace;
+}
+
+function matches(type: IRequestType, setting: string | boolean): boolean {
+  if (setting === true) return true;
+  if (!setting) return false;
+  const needle = String(setting).toLowerCase();
+  return (
+    (type.name || '').toLowerCase().indexOf(needle) >= 0 ||
+    (type.pageUrl || '').toLowerCase().indexOf(needle) >= 0
+  );
+}
+
+/** Типы, за которыми сейчас следим. Пусто — трассировка выключена. */
+export function tracedTypes(types: IRequestType[]): IRequestType[] {
+  const setting = traceSetting();
+  if (!setting) return [];
+  return types.filter((t) => matches(t, setting));
+}
+
+export function traceEnabled(): boolean {
+  return !!traceSetting();
+}
+
+/**
+ * Шаг 1: что вообще пришло из API маршрутов и что из этого пригодно для чтения.
+ *
+ * Тип без listId/siteUrl молча отбрасывается (см. getLinkedTypes) — до поиска
+ * он не доходит вообще, и это первая версия, которую надо исключить.
+ */
+export function traceLinkedTypes(all: IRequestType[], linked: IRequestType[]): void {
+  const setting = traceSetting();
+  if (!setting) return;
+
+  const watched = all.filter((t) => matches(t, setting));
+  if (watched.length === 0) {
+    console.warn(
+      `${PREFIX} Тип по фильтру «${String(setting)}» не найден среди ${all.length} типов из API маршрутов. ` +
+        `Есть: ${all.map((t) => `${t.name} (${t.pageUrl})`).join(', ')}`
+    );
+    return;
+  }
+
+  watched.forEach((t) => {
+    const isLinked = linked.some((l) => l.id === t.id);
+    console.log(`${PREFIX} Тип «${t.name}» (id=${t.id}, ключ=${t.pageUrl}):`, {
+      'дошёл до поиска': isLinked,
+      listId: t.listId ?? '(нет)',
+      siteUrl: t.siteUrl ?? '(нет)',
+    });
+    if (!isLinked) {
+      console.warn(
+        `${PREFIX} Тип «${t.name}» в поиске НЕ участвует: у него нет listId и/или siteUrl ` +
+          `в approval-route API — заполните их в админке, иначе портал не знает, где лежит список.`
+      );
+    }
+  });
+}
+
+/**
+ * Шаг 2–4: KQL, сырые хиты индекса и сопоставление их с адресом списка.
+ *
+ * Path каждого хита сверяется с абсолютным адресом списка (см. hitsToEntries).
+ * Если индекс что-то отдал, а совпадений с этим типом нет — печатаем образцы
+ * путей: расхождение обычно видно глазами (другой сайт, /Lists/ против
+ * человекочитаемого адреса, иной регистр).
+ */
+export function traceSearchHits(
+  label: string,
+  kql: string,
+  types: IRequestType[],
+  results: { PrimarySearchResults: unknown[]; TotalRows?: number },
+  listAbsUrl: (type: IRequestType) => string
+): void {
+  const watched = tracedTypes(types);
+  if (watched.length === 0) return;
+
+  const hits = (results.PrimarySearchResults as Array<Record<string, unknown>>).map((r) =>
+    String(r.Path || '').toLowerCase()
+  );
+
+  // Со слешем на конце — ровно как в боевом сопоставлении (см. listPathPrefix):
+  // иначе трассировка показывала бы «хиты есть» там, где код уже отдал их
+  // другому типу с более коротким адресом (…/Lists/List1 против …/Lists/List10).
+  const prefix = (t: IRequestType): string => `${listAbsUrl(t).toLowerCase().replace(/\/+$/, '')}/`;
+
+  console.log(`${PREFIX} ${label}: запрос отправлен`, {
+    KQL: kql,
+    'хитов получено': hits.length,
+    'TotalRows индекса': results.TotalRows ?? 0,
+  });
+
+  watched.forEach((t) => {
+    const url = prefix(t);
+    const mine = hits.filter((p) => p.indexOf(url) === 0);
+    console.log(`${PREFIX} ${label}: «${t.name}» — хитов индекса ${mine.length}`, {
+      'адрес списка (ожидаемый префикс Path)': url,
+    });
+
+    if (mine.length === 0) {
+      // Индекс мог не отдать НИЧЕГО (тогда дело не в путях), либо отдать
+      // чужие хиты (тогда почти наверняка не совпал префикс).
+      console.warn(
+        `${PREFIX} ${label}: по типу «${t.name}» индекс не вернул ни одного хита. ` +
+          (hits.length === 0
+            ? 'Хитов нет вообще — проверьте сам запрос и права.'
+            : `Пути первых чужих хитов (сравните с ожидаемым префиксом выше): ${hits
+                .slice(0, 5)
+                .join(' | ')}`)
+      );
+    }
+  });
+}
+
+/**
+ * Шаг 5: сколько строк этого типа дожило до выдачи после сопоставления с
+ * адресом списка и дочитывания полей через REST.
+ *
+ * Расхождение «хиты были, строк нет» означает, что элементы из индекса в
+ * списке уже не существуют (удалены, индекс отстал) либо REST их не отдал.
+ */
+export function traceResultRows(
+  label: string,
+  types: IRequestType[],
+  entries: Array<{ type: IRequestType }>,
+  rows: Array<{ requestTypeId: number }>
+): void {
+  const watched = tracedTypes(types);
+  if (watched.length === 0) return;
+
+  watched.forEach((t) => {
+    const mineEntries = entries.filter((e) => e.type.id === t.id).length;
+    const mineRows = rows.filter((r) => r.requestTypeId === t.id).length;
+    console.log(
+      `${PREFIX} ${label}: «${t.name}» — сопоставлено со списком ${mineEntries}, в выдаче ${mineRows}`
+    );
+    if (mineEntries > 0 && mineRows === 0) {
+      console.warn(
+        `${PREFIX} ${label}: по типу «${t.name}» элементы в индексе есть, но ни одной строки ` +
+          `не дочиталось через REST — вероятно, элементы удалены (индекс отстал) или список недоступен.`
+      );
+    }
+  });
+}