Тимур ГородецкийЗаявка в отдел 1С (it-1c-ticket)
Назначение: тикет в отдел 1С — доработки, доступы, ошибки, блокировки. Категория: IT Списки SP: «Заявка в отдел 1С — данные» / «Заявка в отдел 1С — согласование» RequestTypeId (внешний API маршрутов): 10
Маршрут
- Фазы: только согласование. Отдельной фазы исполнения нет — после того как согласование пройдено (или если для вида работ оно не требуется), заявка сразу уходит не исполнителю из матрицы, а в 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"в ответеresolveapproval-route резолвит сам по своей оргструктуре — это не всегда тот, кого заявитель вписал/выбрал в поле «Руководитель» (ContactSection,PeopleTextField).managerOverride.tsпосле загрузки планируемой матрицы находит строку с этимpositionCodeи подставляет туда email/ФИО изdata.Managerвместо того, что вернул resolve. Пустое/нераспознанное значение поля → шаг остаётся без исполнителя, это ловит тот жеunassignedStepMessage, что и обычный незаполненный шаг. Работает только для НОВОЙ заявки (positionCodeесть только у планируемого маршрута, не у уже записанных строк списка согласования).
Особое поведение
- Контакты заявителя предзаполняются через Microsoft Graph (
/me): ФИО, email, телефон, отдел, должность — единственная форма портала, которая это делает (services/profile.service.ts, только для новой заявки, при ошибке Graph — просто остаётся пусто, без ошибки формы). - Planner вместо фазы исполнения. Когда маршрут согласования полностью пройден
(или изначально пуст) —
Ticket1CForm/Ticket1CViewсоздают карточку в Microsoft Planner черезservices/plannerTicket.service.ts(api.tnsu.kz/Planner/CreateTask): рабочий бакет — при согласовании, отдельный бакет «Отклонённые» — при отклонении (с указанием, кто отклонил и по какой причине). Id созданной карточки сохраняется в колонкуPlannerTaskId— это защита от повторного создания карточки, если решение применяется из нескольких вкладок/сессий одновременно. - Ошибку резолва маршрута (например, если в админке маршрутов ещё не настроен маршрут для этого вида работ) форма не путает с «согласование не требуется» — отправка блокируется с понятным сообщением, а не молча уходит в Planner в обход согласования.
- Условные шаги маршрута в SharePoint-списке согласования не хранятся отдельно — это функциональность внешнего approval-route API (настраивается в его собственной админке, вне этого репозитория).
Секции формы
RequestSection · ContactSection
Точки входа
- rptype:
it-1c-ticket - Режим согласующего (просмотр): есть (
Ticket1CView) - «Создать на основе»: нет