Реальная причина бага с дублем в списке согласования: один и тот же
человек может иметь несколько email в справочнике api.tnsu.kz, поэтому
схлопывание по email его не ловило.
EmployeeDirectoryInfo дополнен полем Id (Guid сотрудника из /Employee/
ByEmail). ResolveStepAsync теперь параллельно с email несёт этот Id
(внутренний ResolvedStepRow, наружу не отдаётся), а CollapseByExecutorIdentity
и RemoveCompanyDirectorsDuplicatedByDirectorTansu дедуплицируют по
identity-ключу: Id, если он резолвился, иначе email как фолбэк (на случай,
если сотрудник по итоговому email не нашёлся в справочнике).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Возврат к удалению совпавшей строки CompanyDirectors вместо
последовательной постановки после блока (см. 40d741c) — решили не
показывать одного и того же человека дважды в списке согласования.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Покрывает ровно тот сценарий, который выглядел как баг на скриншоте из
ManageRequestsScreen (один и тот же человек дважды на одном шаге) —
подтверждает, что текущий код (CollapseByExecutorEmail) схлопывает такую
пару в одну строку без предупреждения.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Вместо удаления совпавшей строки CompanyDirectors — обе строки (директор
компании и Директор Tansu) остаются в результате, это два разных пункта
согласования, даже если физически один человек. Строка DirectorTansu,
чей email совпал с одним из CompanyDirectors, не участвует в обычном
схлопывании по email (CollapseByExecutorEmail) — та восприняла бы это как
конфликт PositionCode одного согласующего. Вместо этого её OrderNo явно
переставляется на «сразу после блока CompanyDirectors» (максимальный
OrderNo блока + 1), так что она идёт последовательно, а не параллельно
остальным директорам компаний.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
gorbenko.pavel
gorbenko.pavel