request-portal/src/webparts/requestPortal/forms/Ticket1C

Заявка в отдел 1С (it-1c-ticket)

Назначение: тикет в отдел 1С — доработки, доступы, ошибки, блокировки. Категория: IT Списки SP: «Заявка в отдел 1С — данные» / «Заявка в отдел 1С — согласование» RequestTypeId (внешний API маршрутов): 10

Маршрут

• Фазы: согласование + исполнение. Шаги согласования условные (вид работ/отдел), шаг исполнения — сотрудник отдела 1С (в маршруте №8 без условия). После согласования заявка «Выполнение» у исполнителя; он отмечает «Выполнено» → «Закрыта». Если для вида работ согласование не требуется — заявка сразу «Выполнение». Работу отдел 1С ведёт в карточке Microsoft Planner (см. «Особое поведение»).

• Особенности: маршрут условный — набор шагов зависит от полей «Виды работ» (WorkType) и «Отдел» (Department, свободный текст из профиля AAD, см. «Особое поведение»), которые передаются в resolveRoute/getPlannedMatrix через параметр fieldValues: [{ fieldName: 'WorkType', value: data.WorkType }, { fieldName: 'Department', value: data.Department }] (см. IResolveFieldValue в shared/approval/models/IApprovalRouteApi.ts). В админке маршрутов условие по отделу настроено оператором «содержит» (напр. «Department содержит Бухгалтерия»), поэтому важно фактическое значение поля, а не Id из справочника — отдельного DepartmentId у этой формы нет. Для части видов работ маршрут пуст — согласование не требуется вовсе.

• Матрица нередактируема заявителем (в отличие от WorkplaceSetup/RecruitingHire): раз маршрут однозначно определён видом работ, у заявителя нет ни UserPicker'а, ни кнопок добавить/удалить/переставить шаг — useMatrixEditor вызывается с editable=false даже в форме подачи, не только в просмотре. Если шаг маршрута не разрешился в конкретного человека — отправка блокируется с просьбой обратиться к администратору маршрутов (сам заявитель это не чинит).

• Шаг «Руководитель» переопределяется полем формы. Роль с positionCode: "Chief" в ответе resolve approval-route резолвит сам по своей оргструктуре — это не всегда тот, кого заявитель вписал/выбрал в поле «Руководитель» (ContactSection, PeopleTextField). managerOverride.ts после загрузки планируемой матрицы находит строку с этим positionCode и подставляет туда email/ФИО из data.Manager вместо того, что вернул resolve. Пустое/нераспознанное значение поля → шаг остаётся без исполнителя, это ловит тот же unassignedStepMessage, что и обычный незаполненный шаг. Работает только для НОВОЙ заявки (positionCode есть только у планируемого маршрута, не у уже записанных строк списка согласования).

• Исполнители сами заменяют и удаляют друг друга в поданной заявке (useExecutorEditing.ts): любой исполнитель с невыполненным шагом может заменить или убрать невыполненного исполнителя, в т.ч. активного и себя. Выполненные шаги не трогаются, последнего невыполненного — только заменить. Карточка Planner на людей не назначается, поэтому замена её не затрагивает.

Особое поведение

• Контакты заявителя предзаполняются через Microsoft Graph (/me): ФИО, email, телефон, отдел, должность — единственная форма портала, которая это делает (services/profile.service.ts, только для новой заявки, при ошибке Graph — просто остаётся пусто, без ошибки формы).
• Planner вместе с фазой исполнения (plannerHandoff.ts). Когда заявка доходит до исполнения («Выполнение» — после согласования в Ticket1CView или сразу при отправке в Ticket1CForm, если согласование не требуется), создаётся карточка в Microsoft Planner через services/plannerTicket.service.ts (api.tnsu.kz/Planner/CreateTask) — рабочий бакет; при отклонении — бакет «Отклонённые» (кто отклонил и по какой причине). Маршрут без шага исполнения («Согласовано») тоже уходит в рабочий бакет. Отметку «Выполнено» исполнитель ставит в портале — Planner с порталом не синхронизируется. Id созданной карточки сохраняется в колонку PlannerTaskId — это защита от повторного создания карточки, если решение применяется из нескольких вкладок/сессий одновременно.
• Ошибку резолва маршрута (например, если в админке маршрутов ещё не настроен маршрут для этого вида работ) форма не путает с «согласование не требуется» — отправка блокируется с понятным сообщением, а не молча уходит в Planner в обход согласования.
• Условные шаги маршрута в SharePoint-списке согласования не хранятся отдельно — это функциональность внешнего approval-route API (настраивается в его собственной админке, вне этого репозитория).

Секции формы

RequestSection · ContactSection

Точки входа

• rptype: it-1c-ticket
• Режим согласующего (просмотр): есть (Ticket1CView)
• «Создать на основе»: нет