Шаг 1 СТ: поиск по номеру потребности — на сервере #5

New Issue

2026-10-27T09:43:37Z

timur.gorodetskiy commented

2026-10-27 09:43:37 +00:00

Источник

Кто: Асиля Сарниязова
Когда: 2026-10-23
Где: Teams

Первый шаг - выбор потребностей, долгая загрузка потребностей, если срок превышает 7 дней и по номеру заявки также ищет долго.

Суть

Поиск по номеру потребности на Шаге 1 СТ — в браузере: портал грузит все потребности за период (GET /Requests/{days}) и фильтрует их includes. Найти старую потребность — значит поднять период и ждать загрузки сотен потребностей ради одной.

API умеет искать сам: GET /Requests/{days}?requestNumber=…. Проверено 2026-10-27 в Scalar:

поиск ограничен периодом days — так и задумано;
ищет по части номера (081/26 → все 081/26…).

Делаем: номер из поля поиска уходит в requestNumber, сервер возвращает только совпадения за период. Выбранные позиции и закреплённые потребности СТ при поиске не теряются.

Пункт «долгая загрузка без поиска» (большой период без номера) — скорость самого API, уже исправлена (по словам Тимура, 2026-10-27).

Как проверить

Период 365, номер 081/26 — список приходит быстро, только 081/26….
Очистить поиск — снова все потребности периода.
Выбрать позиции, найти другую потребность, выбрать там, очистить поиск, «Сохранить» — сохранены позиции из обеих.

Сделано

3a6aaa4 — поиск через ?requestNumber= с паузой 500 мс; карта выбранных позиций копится (выбор не теряется при поиске и смене периода)
9b0135b — CHANGELOG

Проверено руками

2026-10-27, воркбенч: п.1–3 (быстрый поиск по части номера, очистка поиска, выбор из двух поисков сохраняется)

Закрыть при выкатке.

## Источник - Кто: Асиля Сарниязова - Когда: 2026-10-23 - Где: Teams > 1. Первый шаг - выбор потребностей, долгая загрузка потребностей, если срок превышает 7 дней и по номеру заявки также ищет долго. ## Суть Поиск по номеру потребности на Шаге 1 СТ — в браузере: портал грузит **все** потребности за период (`GET /Requests/{days}`) и фильтрует их `includes`. Найти старую потребность — значит поднять период и ждать загрузки сотен потребностей ради одной. API умеет искать сам: `GET /Requests/{days}?requestNumber=…`. Проверено 2026-10-27 в Scalar: - поиск ограничен периодом `days` — так и задумано; - ищет по части номера (`081/26` → все `081/26…`). Делаем: номер из поля поиска уходит в `requestNumber`, сервер возвращает только совпадения за период. Выбранные позиции и закреплённые потребности СТ при поиске не теряются. Пункт «долгая загрузка без поиска» (большой период без номера) — скорость самого API, уже исправлена (по словам Тимура, 2026-10-27). ## Как проверить 1. Период 365, номер `081/26` — список приходит быстро, только `081/26…`. 2. Очистить поиск — снова все потребности периода. 3. Выбрать позиции, найти другую потребность, выбрать там, очистить поиск, «Сохранить» — сохранены позиции из обеих. ## Сделано - `3a6aaa4` — поиск через `?requestNumber=` с паузой 500 мс; карта выбранных позиций копится (выбор не теряется при поиске и смене периода) - `9b0135b` — CHANGELOG ## Проверено руками - [x] 2026-10-27, воркбенч: п.1–3 (быстрый поиск по части номера, очистка поиска, выбор из двух поисков сохраняется) Закрыть при выкатке.

timur.gorodetskiy added the perf форма/СТ

приоритет

обычный

labels 2026-10-27 09:43:37 +00:00

timur.gorodetskiy referenced this issue from a commit

2026-10-27 10:01:59 +00:00

feat(ct): поиск по номеру потребности на шаге 1 — на сервере (#5)

timur.gorodetskiy referenced this issue from a commit

2026-10-27 10:01:59 +00:00

docs: CHANGELOG — серверный поиск на шаге 1 (#5)

Sign in to join this conversation.