Files
request-portal/docs/forms.md
T
Тимур Городецкий 7e9848e83d
Tests / frontend-test (push) Successful in 1m17s
feat: форма «Объяснительная по СКУД»
Сотрудник пишет объяснительную за дни без отметок СКУД, выбирая их кликом
в календаре «Мой СКУД» (перенесён из portal-main-page: те же цвета и
правила, проходы Hikvision текущего пользователя, праздники из
«Производственного календаря»). Текст записки собирается автоматически,
в просмотре печатается бланк объяснительной.

- выбираются прошедшие дни < 8 ч, с одной записью или без отметок и
  сегодня без отметок; только текущий и прошлый месяц;
- дни сохраняются снимком (JSON), т.к. согласующий чужой СКУД не видит;
- защита от повторов: дни из уже поданных объяснительных помечены ✓ и
  не выбираются, перед отправкой список перечитывается;
- маршрут в две фазы: согласование + исполнение (кадры);
- дата подачи ставится автоматически.

Плитка пока только для тестировщиков (comingSoon): списки SP
провизионированы, тип и маршрут заведены, осталась проверка e2e.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 17:27:46 +05:00

8.4 KiB
Raw Blame History

Формы портала заявок — индекс

Каждая форма живёт в своей папке src/webparts/requestPortal/forms/<Форма>/ и имеет рядом README.md — карточку с её бизнес-поведением (то, что не видно из кода с первого взгляда). Здесь — общий индекс.

Правило (при добавлении формы)

  1. Папка forms/<Форма>/ + README.md по шаблону.
  2. Строка в индексе ниже.
  3. Строка в forms/registry.ts (ленивая форма) и, если есть режим согласующего, в forms/viewRegistry.ts.
  4. Плитка в data/requests.ts.

Формы больше не хардкодят RequestTypeId

Числовой id типа заявки во внешнем approval-route API (GET /api/request-types) выдаётся сервером при регистрации типа в админке и непредсказуем заранее (в старой pto-tracker у «отпуска» было 1, при заведении типа в новой админке он получил id 11). Раньше каждая форма хардкодила это число константой вида VACATION_REQUEST_TYPE_ID = 11; теперь — резолвит его в рантайме по своему pageUrl (тот же rptype, что и id в data/requests.ts) через useRequestTypeId(context, pageUrl) (shared/approval). Результат кешируется на уровне модуля на время сессии (см. getRequestTypeIdByPageUrl в approvalRoute.service.ts) — повторный вызов из другой формы не бьёт по сети заново.

  • Форма подачи знает свой pageUrl из пропа requestType.id.
  • Режим согласующего (<Форма>View) получает его пропом formKey (см. IApprovalViewProps в forms/viewRegistry.ts и ApproveFeature.tsx).

Что НЕ дублируем в карточке (лежит в других местах)

  • Колонки списков → forms/<Форма>/provisioning.json.
  • Параметры ссылок (rptype/rpmode/rpid/rpsource) → routing.md.
  • Особые права (кто что может сверх обычного, по email/должности/группе) → permissions.md.
  • Как обращаться к спискам SP из кода → sp-lists-frontend.md.
  • Общий жизненный цикл (черновик/upsert/блокировка/статусы), согласование, исполнение, печать — одинаковы для всех форм (общие примитивы shared/ui и shared/approval).

Карточка — только про то, чем эта форма отличается.


Индекс форм

Ключ (rptype) Форма Категория Согл. Исп. Просмотр Фишки Готово
recruiting-selection Заявка на подбор Рекрутинг нет нет нет много полей (~42), поля-люди (в т.ч. мульти) ✅
recruiting-hire Заявка на прием Рекрутинг да да да маска телефона, деньги, условное «взамен кого», источник для орг. места ✅
recruiting-referral Реферальная рекомендация Рекрутинг да да да кандидат — внешний (текстовые поля, не People); маршрут по рекомендателю; исполнитель переназначает на реального; условное уточнение «откуда знаете» ✅
it-workplace-setup Организация рабочего места IT да да да префилл из «прием», поля ПО/доступы правит руководитель ✅
it-1c-ticket Заявка в отдел 1С IT да нет да контакты предзаполняются из Graph (/me); вместо фазы исполнения — карточка в Microsoft Planner (согласовано/сразу без согласования — рабочий бакет, отклонено — отдельный бакет) ✅
clearance-form Обходной лист Отдел кадров да нет да подаётся HR за увольняемого (People-picker) либо создаётся сам по согласованному «Заявлению на увольнение»; условие «IsManager» резолвится по должности из самой заявки; да/нет-поля (парковка, СКУД); 5 независимых сумм к списанию компактной сеткой (ОС, СИЗ, подотчётная сумма, НМА, ТМЦ — обучение не входит, у него своё поле) — вводит любой активный согласующий, блокируется навсегда после первого ввода; заполнил хоть одну — стандартный комментарий решения (в блоке «Ваше решение») становится обязательным на любое решение, не только возврат/отклонение ✅
hr-dismissal Заявление на увольнение Отдел кадров да нет да совместители — таблица компаний с удалением строки (снимает и согласующего из матрицы); должность/организация из справочника; после согласования сам создаёт обходной лист; печать заблокирована до согласования обходного листа; «Лицо, принимающее ОС/НМА» — заполняет только непосредственный руководитель ✅
hr-skud-explanation Объяснительная об отсутствии отметок в СКУД Отдел кадров да нет да только «на себя»; дни выбираются кликом в календаре «Мой СКУД» (проходы Hikvision текущего пользователя), сохраняются снимком для согласующего; текст записки собирается автоматически, печать — бланк объяснительной ⏳ код готов, списки/тип/маршрут не заведены
hr-transfer Перемещение сотрудников Отдел кадров — — — — ⏳ заглушка (плитка есть, форма не сделана)
wh-service-request Заявка на услуги Склад / Снабжение да нет да маршрут по проекту (руководитель проекта/ПТО); табличные части «Приложения» и «Смета» (JSON-колонки); сумма по смете считается на лету (qty × цена), итог дублируется числовой колонкой для отчётов ✅

Легенда: Согл. — есть фаза согласования; Исп. — есть фаза исполнения; Просмотр — есть режим согласующего (<Форма>View).