«Создана заявка: Заявка на прием · TNS-… · Инженер — Проект X», «Заявка отправлена на согласование: …»,
«Заявка согласована: TNS-… · …» — заявку видно прямо в списке логов; те же данные — в полях request.*.
Отправка на согласование пишется при сохранении заявки с отправленным статусом (там известно, что за
заявка), из writeRoute лог убран. Код и название для решения дочитываются, сбой чтения решение не ломает.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Маршрут планируется один раз при подаче: если мебель или ПО отметил
руководитель на своём шаге, исполнитель по ним не появлялся. Теперь при
сохранении правок (и перед решением) строятся два плана исполнения — со
старыми и новыми значениями — и разница встаёт в конец исполнения «Ждёт
очереди» с SLA из маршрута. Никого не удаляем, уже стоящих не дублируем;
ошибка добавления не теряется и блокирует решение.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Алтынай Бултурукова (право canEditRoute) просила добавлять участников в уже
поданный маршрут. Новый согласующий или исполнитель встаёт в конец своего
этапа со статусом «Ждёт очереди» (дальше его можно поднять стрелками);
согласующего — пока идёт согласование, исполнителя — пока не завершено
исполнение, без дублей среди ещё не решивших. Заявка «трогается», чтобы
бэкенд выдал новому участнику права на элемент данных.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Алтынай Бултурукова (право canEditRoute) просила менять порядок участников
уже поданной заявки. Стрелки у шагов согласования и исполнения: меняются
местами только соседние шаги одной фазы, оба «Ждут очереди» — активный и
пройденные шаги не трогаются, поэтому никто не теряет заявку и оповещать
некого. Строки перечитываются перед записью, StepOrder пишется одним батчем.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Права на заявку новым участникам маршрута выдаёт бэкенд по вебхуку на
изменение элемента списка данных. Делегирование и замена/удаление
исполнителя меняли только список согласования — вебхук не приходил, и
новый человек видел «Элемент не найден». Теперь после этих действий
заявка перезаписывается с тем же статусом: значение не меняется, но
появляется новая версия элемента и срабатывает вебхук.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
В маршруте №8 есть шаг «Исполнение», но форма 1С запрашивала только
согласование и записывала пустой список исполнителей: после согласования
заявка навсегда оставалась «Согласовано», без исполнителя и даты исполнения.
Теперь исполнитель берётся из маршрута с теми же условиями, заявка идёт
«Выполнение» → «Закрыта», а карточка Planner создаётся при переходе в
исполнение (в т.ч. сразу при отправке, если согласование не требуется).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Начальник отдела подбора (routeEditRights) назначает исполнителей, но
сама в исполнении не стоит. В матрице «Исполнение» заявки на подбор у
шагов «Ждёт очереди» и «На исполнении» появились кнопки «Заменить» и
«Удалить»:
- замена меняет только человека в шаге, активный шаг сразу переходит
к новому исполнителю, ему уходит оповещение;
- при удалении активного очередь переходит к следующему исполнителю;
- выполненные шаги не трогаются, последнего невыполненного исполнителя
можно только заменить — иначе заявка закрылась бы без исполнения.
Остальные формы не затронуты: кнопки включаются пропсами ApprovalMatrix
(canReplaceRow/onReplaceRow) только в RecruitingSelectionView.
notifyActiveStep получил необязательный rowId, чтобы на параллельном
шаге письмо ушло именно новому исполнителю.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
gorbenko.pavel
gorbenko.pavel
timur.gorodetskiy