gorbenko.pavel
cf57b40513
Tests / frontend-test (push) Failing after 38s
Провижининг (Provision-Lists.ps1 читает эти манифесты) теперь заводит колонку «Автосогласование» (AutoApprove, Да/Нет) в каждом из 12 списков согласования — рядом с уже существующими SLAhours/AskOverdueReason. Значение приходит из resolve (approval-route API, шаг маршрута настраивается только в админке — портал само значение не выбирает, только переносит его в строку списка при отправке заявки/сохранении черновика, тем же путём, что и slaHours/askOverdueReason). Фактическое автосогласование по истечении SLA делает фоновая задача бэкенда (Hangfire), не портал. В ApprovalMatrix добавлена пометка «(авто)» рядом со значением SLA — чисто информативно, чтобы участник видел, что решение по шагу может принять не только человек. Примечание: ServiceRequest и TmcTransfer не передают ни slaHours/ askOverdueReason, ни (теперь) autoApprove из resolve в строку — это существовавший пробел (SLA на уровне шага у этих двух форм и раньше не работал), автосогласование для них наследует только это же ограничение. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: gorbenko.pavel <gorbenko.pavel@tansu.kz> Reviewed-on: http://git.tnsu.kz/timur.gorodetskiy/request-portal/pulls/20
Заявка на перемещение сотрудника (hr-transfer)
Назначение: заявление сотрудника директору ТОО с просьбой перевести его на
другую должность и/или в другое подразделение. Бумажный первоисточник — типовой
бланк «Заявление» (перевод) с согласованием начальника подразделения.
Категория: Отдел кадров
Списки SP: «Заявка на перемещение сотрудника — данные» / «Заявка на перемещение сотрудника — согласование»
RequestTypeId (внешний API маршрутов): не хардкодится — резолвится в рантайме по
pageUrl («hr-transfer») через useRequestTypeId (см. «Формы больше не хардкодят
RequestTypeId» в docs/forms.md). Тип и маршрут нужно завести в админке approval-route.
Маршрут
- Фазы: только согласование. Фазы исполнения нет — после согласования заявка получает статус «Согласовано» (как «Заявка на отпуск» / «Отпуск без содержания»).
- Матрица редактируема заявителем при новой заявке / черновике / возврате:
useMatrixEditor(editable = !readOnly). - Запланированный шаблон маршрута (approval-route, заводится в админке): шаг 1 —
HeadType.Chief(непосредственный руководитель сотрудника), шаг 2 —HeadType.CompanyDirectors(директор компании сотрудника, как в «Заявлении на увольнение») — по бумажному шаблону заявление адресовано директору ТОО, а согласовывает его начальник подразделения.
Особое поведение
- По умолчанию заявка на себя, но подать можно и за другого: «Сотрудник» —
People-picker (
Employee), маршрут резолвится по e-mail выбранного сотрудника, reloadKey матрицы включаетdata.Employee. - Автоподстановка при выборе сотрудника: текущая должность (
Position, редактируема — справочник не всегда точен) и организации (Organization, read-only,OrganizationField) — изEmployee/ByEmail(shared/dictionary), тот же приём, что у «Заявки на отпуск». - Новая должность (
NewPosition) — свободный текст. - Новое подразделение (
NewDepartment/NewDepartmentId) — справочникDictionary/Departments(shared/dictionary/DepartmentPicker), не влияет на маршрут (справочное поле, как «Подразделение» в «Заявке на отпуск»). - Дата перевода (
TransferDate) — обязательна, ограничений по сроку уведомления (в отличие от отпуска/увольнения) шаблон не задаёт. - Комментарий (
Comment) — необязательный свободный текст. - Заголовок элемента (
Title):Перемещение — {ФИО} — дд.мм.гггг. - Печать (
PrintSplitButton/OrgLetterhead) — как у «Заявки на отпуск»: сотрудник может состоять сразу в нескольких организациях, печатается бланк с шапкой выбранной компании.
Секции формы
RequestSection (сотрудник · текущая должность · организация (read-only) · дата перевода · новая должность · новое подразделение · комментарий)
Точки входа
- rptype:
hr-transfer - Режим согласующего (просмотр): есть (
EmployeeTransferView) - «Создать на основе»: нет