Направление работ: WebLk Код раздела: 3.6 Профиль партнёра > Сотрудники и доступ Статус: Готов Ответственный: Панкова Л.А. Версия: 0.2 + сверка с кодом 04.09.26 Обновлено: 04.09.26 (первая сверка — 24.08.26)
1. Назначение
Данный раздел обеспечивает партнеру интерфейс для просмотра сотрудников партнерской зоны и управления их доступом.
Партнер просматривает сотрудников по ролям и состояниям аккаунта, добавляет и редактирует сотрудников, создает и настраивает роли, а также архивирует, удаляет и восстанавливает сотрудников.
Партнер распоряжается тем, что относится к его зоне: объектами, ролью и архивацией. Персональные данные сотрудника — имя, фамилию, email, фотографию и пароль — вводит и меняет сам сотрудник; партнер их не заполняет и не правит.
Интерфейс учитывает привязку сотрудников к объектам партнерской зоны и показывает доступные действия в зависимости от прав текущего пользователя.
Раздел опирается на Back: 1.1 «Организация аккаунтов», Back: 1.2 «Организация доступа к системе», Back: 1.2.1 «Группировка по ролям и тарифам», Back: 1.4.1 «Партнерская зона доступа» и Back: 2.8 «Настройки партнерской зоны».
2. Ключевые понятия
Сотрудники и доступ — раздел кабинета партнера для просмотра сотрудников, управления ролями и настройки доступов в рамках текущей партнерской зоны.
Партнерская роль — набор доступов, который партнер назначает сотруднику в рамках конкретной партнерской зоны.
Партнерская зона доступа — область, в пределах которой сотруднику назначаются роли, объекты и доступные действия.
Карточка сотрудника — представление сотрудника в разделе с ролью, именем, контактами, связанными объектами и состоянием аккаунта. У приглашенного, который еще не назвал себя, имя и email пустые — интерфейс показывает на их месте прочерк.
Приглашение сотрудника — заведение сотрудника по одному номеру телефона. Владелец зоны вводит номер, роль и объекты; имя, фамилию и email вводит сам сотрудник при первом входе. Приглашение завершается дозаполнением профиля и подтверждением email — см. Back: 1.1, переход I.
Доступ ко всем объектам зоны — признак конкретного сотрудника, при котором выданные объекты не назначаются вовсе: он работает во всех объектах партнерской зоны, включая те, что появятся позже. Признак принадлежит сотруднику, а не роли: роль общая на всех, кому она выдана, и сказать ею про конкретного человека нельзя.
Активный сотрудник — сотрудник с завершенным приглашением, который отображается в группе «Активные» и отмечается активной иконкой возле роли и аватара.
Приглашенный сотрудник — сотрудник, который еще не завершил приглашение: он мог уже войти и подтвердить номер телефона, но пока не дозаполнил профиль и не подтвердил email. Отображается в группе «Приглашенные» с серой иконкой.
Архивированный сотрудник — сотрудник, переведенный в архив и отображаемый в группе «Архивированные» с красной иконкой.
3. Scope
Входит
- S1. Просмотр сотрудников и ролей
- S2. Приглашение сотрудника по номеру телефона
- S3. Настройка доступа роли
- S4. Добавление роли
- S5. Редактирование списка ролей
- S6. Редактирование сотрудника: объекты, роль, доступ ко всем объектам
- S7. Архивация сотрудника
- S8. Удаление сотрудника
- S9. Восстановление сотрудника
- S10. Состояния интерфейса раздела
- S11. Адаптивное отображение раздела
Не входит
- WebLk 3.1 Главный экран — точка входа в раздел «Сотрудники и доступ».
- WebLk 1.2 Вход — первый вход приглашенного сотрудника, дозаполнение профиля и подтверждение email.
- WebLk 4.1 Объекты — создание, редактирование и управление объектами, к которым назначается доступ сотрудника.
- AdmLk 3.7 Сотрудники и доступ к сервисной зоне — управление сотрудниками и ролями сервисной зоны.
- Правка сотрудником своих персональных данных, фотографии и пароля — мобильное приложение МАРТ.
- Backend-реализация модели доступа, API-контракты, структура БД и внутренняя проверка прав.
4. BR
Связанные BR указаны в пункте 4 разделов:
- Back: 1.1 Организация аккаунтов — матрица состояний Аккаунта, приглашение на архивный номер, судьба аккаунта при увольнении приглашенного.
- Back: 1.1.1 Регистрация — состав данных приглашения, доставка приглашения SMS.
- Back: 1.2 Организация доступа к системе.
- Back: 1.2.1 Группировка по ролям и тарифам.
- Back: 1.4.1 Партнерская зона доступа.
- Back: 2.8 Настройки партнерской зоны.
5. Функциональные требования (UC + FR)
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR3.6-1 | Партнер открывает раздел «Сотрудники и доступ» | Интерфейс показывает выбранную партнерскую зону, список ролей, переключатели состояний сотрудников, поиск, настройку доступов и область с карточками сотрудников с возможностью добавления. | 1 | Частично OQ3.6-11 | |
| S1: FR3.6-2 | Партнер открывает раздел до первого добавления сотрудников | Интерфейс показывает только карточку владельца партнерской зоны. Владелец отображается как активный сотрудник. | 1 | Реализовано | |
| S1: FR3.6-3 | Партнер выбирает роль | Интерфейс показывает сотрудников выбранной роли. Пункт «Все роли» показывает сотрудников всех ролей, включая владельца. | 1 | Реализовано | |
| S1: FR3.6-4 | Партнер переключает состояние сотрудников | Интерфейс позволяет переключаться между состояниями «Все», «Активные», «Приглашенные» и «Архивированные», показывает количество сотрудников в каждом состоянии и фильтрует карточки по выбранному состоянию. | 1 | Реализовано | |
| S1: FR3.6-5 | Партнер ищет сотрудника по ФИО | Интерфейс фильтрует отображаемые карточки сотрудников по введенному ФИО в рамках текущей партнерской зоны. Приглашенный, который еще не назвал себя, по ФИО не находится: имени у него нет — его следует искать по номеру телефона. | 2 | Частично OQ3.6-13 | |
| S1: FR3.6-6 | Партнер просматривает карточку сотрудника | Интерфейс показывает роль и имя сотрудника, состояние аккаунта, доступные контактные данные и связанные объекты. У приглашенного, который еще не дозаполнил профиль, имя и email пустые — на их месте показывается прочерк. Активный сотрудник отмечается активной иконкой возле роли и аватара, приглашенный — серой иконкой, архивированный — красной иконкой. | 1 | Частично OQ3.6-16 | |
| S1: FR3.6-7 | Партнер просматривает сотрудника, связанного с несколькими объектами | Интерфейс сокращенно показывает список объектов в карточке и позволяет раскрыть полный список связанных объектов, а затем свернуть его. У сотрудника с доступом ко всем объектам зоны выданных объектов нет ни одного — в поле «Объект» вместо пустоты подставляется текст о доступе ко всем объектам. | 2 | Реализовано | |
| S1: FR3.6-8 | Партнер просматривает историю изменений. (на будущую реализацию) | Интерфейс открывает панель «История» для выбранного сотрудника и показывает события с датой и временем, разделом, действием, исходными и текущими данными. | 3 | Не реализовано (вес 3, на будущее) | |
| S2: FR3.6-9 | Партнер начинает приглашение сотрудника в существующую роль | Интерфейс позволяет сначала выбрать роль в боковом списке, раскрывает панель выбранной роли и показывает действие «+» для добавления сотрудника именно в эту роль. | 1 | Частично OQ3.6-5 | |
| S2: FR3.6-10 | Партнер открывает форму приглашения сотрудника | Интерфейс открывает панель «Добавление сотрудника» с блоками «Контактные данные» и «Настройки». | 1 | Реализовано | |
| S2: FR3.6-11 | Партнер вводит телефон сотрудника | Обязательным полем формы является «Телефон». После ввода номера интерфейс инициирует поиск аккаунта сотрудника и определяет дальнейший сценарий входа. | 1 | Частично OQ3.6-4 | |
| S2: FR3.6-12 | Партнер назначает сотруднику объекты | Интерфейс позволяет выбрать один, несколько или все доступные объекты партнерской зоны и показывает выбранные объекты в форме сотрудника. | 1 | Реализовано | |
| S2: FR3.6-13 | Партнер дает сотруднику доступ ко всем объектам зоны | Интерфейс показывает признак «работает во всех объектах зоны». Пока он включен, выбор объектов скрыт и выданные объекты не назначаются вовсе: сотруднику доступны все объекты зоны, включая те, что появятся позже. Признак относится к конкретному сотруднику, а не к его роли. | 1 | Реализовано | |
| S2: FR3.6-14 | Партнер проверяет назначенную роль | Интерфейс автоматически подставляет роль, из которой начато добавление сотрудника, и позволяет выбрать другую существующую роль. Пункт «Добавить роль» запускает отдельный сценарий S4. | 3 | Не реализовано OQ3.6-5 | |
| S2: FR3.6-15 | Партнер сохраняет сотрудника | Интерфейс показывает действие «Сохранить». | 1 | Частично OQ3.6-4 | |
| S2: FR3.6-16 | Номер принадлежит архивному аккаунту | Интерфейс показывает отказ: пригласить такой номер нельзя, человек восстанавливает учетную запись сам, зарегистрировавшись заново. Чей это аккаунт и почему он архивирован, владельцу зоны не сообщается. | 1 | Частично OQ3.6-14 | |
| S2: FR3.6-17 | Партнер приглашает сотрудников подряд | Приглашение ограничено по частоте: SMS платная и приходит человеку, который в системе еще никто. При превышении лимита интерфейс показывает отказ с предложением повторить позже. | 2 | Частично (вес 2, попутно) | |
| S2: FR3.6-18 | Приглашен сотрудник с действующим аккаунтом | Если у человека уже подтверждены и номер, и email — либо он уже работает сотрудником в другой зоне, — приглашение принимается сразу: интерфейс показывает его в группе «Активные», увеличивает счетчик группы и отмечает карточку активной иконкой. Интерфейс показывает уведомление о том, что сотрудник есть в системе и инструкция для входа будет отправлена на подтвержденную почту. | 1 | Частично OQ3.6-4, OQ3.6-15 | |
| S2: FR3.6-19 | Приглашен сотрудник без действующего аккаунта | После сохранения интерфейс создает пустую карточку сотрудника в группе «Приглашенные» без фотографии, имени и почты, увеличивает счетчик группы и отмечает карточку серой иконкой. После первого входа сотрудник отображается в группе «Активные» с активной иконкой и обновленными данными. | 1 | Частично OQ3.6-3 | |
| S2: FR3.6-20 | Сотруднику отправляется инструкция для входа. В зависимости от состояния аккаунта возможны следующие сценарии | Интерфейс инициирует отправку инструкции для входа в зависимости от состояния аккаунта: - аккаунта нет — отправляется SMS с паролем и инструкцией для входа; - аккаунт есть, телефон не подтвержден — отправляется SMS с паролем и инструкцией для входа; - аккаунт есть, телефон подтвержден, почта отсутствует или не подтверждена — отправляется SMS с инструкцией для входа без пароля; сотрудник входит под своими данными; - аккаунт есть, телефон и почта подтверждены — на подтвержденную почту отправляется инструкция для входа; сотрудник входит под своими данными. Тексты сообщений будут уточнены позже. Примерный формат сообщения: «Вы добавлены в партнерскую зону Hendrix Studio в качестве сотрудника. Ссылка на вход Пароль: 4523HFKjd/р». | 1 | Частично OQ3.6-4, OQ3.6-15 | |
| S3: FR3.6-21 | Партнер открывает настройки доступа роли | Интерфейс открывает панель «Редактирование доступа роли» для выбранной роли по нажатию кнопки настройки в панели роли. | 1 | Частично OQ3.6-6 | |
| S3: FR3.6-22 | Партнер просматривает настройки доступа роли | Интерфейс показывает название и описание роли, группы доступов и доступные настройки. Полный и изменяемый состав доступов определяется актуальной таблицей. | 1 | Реализовано | |
| S3: FR3.6-23 | Партнер изменяет доступ роли | Интерфейс позволяет включать и отключать доступные настройки просмотра и редактирования. Состав настроек соответствует таблице и может изменяться. | 1 | Реализовано | |
| S3: FR3.6-24 | Партнер раскрывает группу доступов | Интерфейс позволяет раскрывать и сворачивать группы настроек доступа, сохраняя выбранные значения в текущей форме. | 2 | Не реализовано (вес 2, попутно) | |
| S3: FR3.6-25 | Партнер завершает настройку доступа роли | Интерфейс позволяет сохранить изменения или отменить редактирование. После успешного сохранения новые настройки применяются к выбранной роли. | 1 | Частично OQ3.6-6 | |
| S4: FR3.6-26 | Партнер нажимает «Добавить роль» в разделе | Интерфейс открывает панель «Создание доступа роли». | 1 | Реализовано | |
| S4: FR3.6-27 | Партнер заполняет данные новой роли | Интерфейс позволяет указать обязательное название роли и добавить описание, помогающее различать роли в разделе. | 1 | Реализовано | |
| S4: FR3.6-28 | Партнер настраивает доступ новой роли | Интерфейс позволяет настроить доступ новой роли. Полный и изменяемый состав доступов определяется таблицей. Признака доступа ко всем объектам у роли нет: он принадлежит сотруднику — см. FR3.6-13. | 1 | Частично OQ3.6-17 | |
| S4: FR3.6-29 | Партнер сохраняет или отменяет создание роли | Действие сохранения недоступно, пока обязательное название роли не заполнено. После сохранения интерфейс добавляет роль в список ролей и делает ее доступной для назначения сотрудникам. При отмене новая роль не появляется в списке. | 1 | Реализовано | |
| S5: FR3.6-30 | Партнер открывает редактирование списка ролей | По нажатию кнопки настройки рядом с действием «Добавить роль» интерфейс переводит список ролей в режим редактирования. | 1 | Реализовано | |
| S5: FR3.6-31 | Партнер изменяет порядок ролей. (на будущую реализацию) | Интерфейс позволяет перетаскивать роли и изменять порядок их отображения в боковом списке. | 3 | Не реализовано (вес 3, на будущее) | |
| S5: FR3.6-32 | Партнер удаляет лишние роли из списка | Интерфейс позволяет перейти к настройке роли и удалить роль при условии, что в ней нет действующих сотрудников. | 1 | Частично OQ3.6-6 | |
| S5: FR3.6-33 | Партнер завершает редактирование списка ролей | По нажатию «Готово» интерфейс сохраняет состав и порядок ролей и возвращает список в обычный режим. | 1 | Частично OQ3.6-6 | |
| S6: FR3.6-34 | Партнер выбирает карточку сотрудника | Интерфейс выделяет выбранную карточку и открывает панель «Редактирование» с данными сотрудника. | 1 | Частично OQ3.6-9 | |
| S6: FR3.6-35 | Партнер изменяет данные сотрудника | Интерфейс позволяет изменять только объекты и роль сотрудника. | 1 | Реализовано | |
| S6: FR3.6-36 | Партнер изменяет объекты сотрудника | Интерфейс позволяет выбрать один, несколько или все объекты либо включить доступ ко всем объектам зоны и показывает обновленный список объектов в форме и карточке сотрудника. Снятый объект отзывается явно, а не пропадает из списка молча. | 1 | Реализовано | |
| S6: FR3.6-37 | Партнер изменяет роль сотрудника | Интерфейс позволяет выбрать другую существующую роль для сотрудника. После сохранения карточка отображается в соответствующей роли. | 1 | Реализовано | |
| S6: FR3.6-38 | Партнер завершает редактирование сотрудника | Интерфейс делает действие сохранения доступным после изменения данных, позволяет сохранить изменения или отменить редактирование. В сохранение уходят только объекты, роль и признак доступа ко всем объектам — контакты и имя интерфейс не отправляет вовсе. После успешного сохранения карточка показывает актуальные данные сотрудника. | 1 | Частично OQ3.6-9 | |
| S7: FR3.6-39 | Партнер инициирует архивацию сотрудника | В панели редактирования активного сотрудника интерфейс позволяет выбрать действие «Архивировать». | 1 | Реализовано | |
| S7: FR3.6-40 | Партнер подтверждает архивацию сотрудника | Интерфейс показывает подтверждение «Вы уверены, что хотите архивировать сотрудника?» и позволяет подтвердить или отменить действие. | 1 | Реализовано | |
| S7: FR3.6-41 | Сотрудник архивирован | После подтверждения интерфейс переносит карточку в группу «Архивированные», обновляет счетчики и отмечает карточку красной иконкой. Вместе с сотрудником отзываются выданные ему объекты этой зоны — иначе они пережили бы увольнение и вернулись при повторном найме. | 1 | Реализовано | |
| S7: FR3.6-42 | Архивирован приглашенный, который ни разу не входил | Вместе со связью отзывается и его учетная запись: она заводилась приглашением и не пригодилась. Приглашенный, успевший войти, при архивации остается жить — аккаунтом он пользуется, и зона им не распоряжается. Правило и его причина — Back: 1.1 BR1.1-17, переходы O и P. | 1 | Реализовано | |
| S7: FR3.6-43 | Партнер отменяет архивацию сотрудника | Интерфейс закрывает подтверждение и сохраняет сотрудника в текущем состоянии без изменений. | 1 | Реализовано | |
| S8: FR3.6-44 | Партнер инициирует удаление архивированного сотрудника. (на будущую реализацию) | В панели архивированного сотрудника интерфейс позволяет выбрать действие «Удалить». | 3 | Не реализовано (вес 3, на будущее) OQ3.6-12 | |
| S8: FR3.6-45 | Партнер подтверждает удаление сотрудника. (на будущую реализацию) | Интерфейс показывает подтверждение «Вы уверены, что хотите удалить сотрудника?» и позволяет подтвердить или отменить действие. | 3 | Не реализовано (вес 3, на будущее) OQ3.6-12 | |
| S8: FR3.6-46 | Сотрудник удален из интерфейса. (на будущую реализацию) | После подтверждения интерфейс больше не показывает сотрудника в списке и обновляет счетчик архивированных. Удаление выполняется только в интерфейсе; для сервиса сотрудник остается в архиве. | 3 | Не реализовано (вес 3, на будущее) OQ3.6-12 | |
| S8: FR3.6-47 | После удаления в роли нет сотрудников. (на будущую реализацию) | Интерфейс показывает описание выбранной роли и доступные действия для добавления сотрудника и настройки доступа роли. | 3 | Не реализовано (вес 3, на будущее) OQ3.6-12 | |
| S9: FR3.6-48 | Партнер инициирует восстановление сотрудника | В панели архивированного сотрудника интерфейс позволяет выбрать действие «Восстановить». | 1 | Реализовано | |
| S9: FR3.6-49 | Партнер подтверждает восстановление сотрудника | Интерфейс показывает подтверждение «Вы уверены, что хотите восстановить сотрудника?» и позволяет подтвердить или отменить действие. | 1 | Реализовано | |
| S9: FR3.6-50 | Сотрудник восстановлен | После подтверждения интерфейс возвращает карточку в ту группу, в которой сотрудник был до архивации: активный возвращается в «Активные», приглашенный с незавершенным приглашением — в «Приглашенные». Вместе с сотрудником возвращаются выданные ему объекты этой зоны. Счетчики обновляются. | 1 | Реализовано | |
| S9: FR3.6-51 | Партнер отменяет восстановление сотрудника | Интерфейс закрывает подтверждение и сохраняет сотрудника в архиве без изменений. | 1 | Реализовано | |
| S10: FR3.6-52 | Партнер открывает данные сотрудника без права редактирования | Интерфейс показывает ранее редактируемые поля в режиме просмотра, скрывает действие сохранения и не позволяет изменять данные, объекты, роль или состояние сотрудника. | 1 | Не реализовано OQ3.6-8 | |
| S10: FR3.6-53 | Партнер открывает раздел во время загрузки данных | Интерфейс показывает скелетон для списка ролей и карточек сотрудников до завершения загрузки. | 2 | Частично (вес 2, попутно) | |
| S11: FR3.6-54 | Партнер открывает раздел на поддерживаемом устройстве | Интерфейс адаптирует страницу раздела «Сотрудники и доступ», карточки, связанные блоки и формы редактирования для desktop, laptop, tablet и mobile. | 1 | Частично OQ3.6-10 |
6. Открытые вопросы
Сводка: 17 вопросов — Open 16, Closed 1. Первая сверка от 24.08.26 по требованиям веса 1; вес 2 и 3 не проверялись, расхождения по ним попали в таблицу только там, где встретились попутно. Повторная сверка 04.09.26 — по ветке
employee-invite-sms-stg-athena: кабинет @978ed2c9, бэкенд @2c30bf6d. Что изменилось с 24.08, помечено в вопросах как Обновление 04.09.26.Обновление 08.09.26 (сверка по дейликам). Повторная (дельта) сверка поверх сверки от 04.09.26 на ветке
employee-invite-sms-stg-athena— заново перепроверено каждое требование по текущемуorigin/main, а не скопированы старые статусы. Срез кода: WebLkmusbooking_personal_account@cdfa1dad(2026-09-07), backendbooking-monorepo@82359296(2026-09-07) — оба detached worktree наorigin/main. Маршрутизация без сверки с гайдбуком — гайдбук в этом прогоне не передавался. Технические признаки правильной линии из OQ3.6-1/OQ3.6-2 (распаковка обёрток{roles}/{permissions},partnerZoneIdв архивации роли, код права объектом{domain, category, group, type}, методGetPermissionDictionary, идентити-именаGetRoles/CreateRole/UpdateRole/ArchiveRole) на срезеorigin/mainподтверждены — веткиWebLk-3.6-refactorи раздельного бэкенда как проблемы больше не существует, код сверен прямо наmain. Изменены статусы 5 требований (FR3.6-6, FR3.6-24, FR3.6-28, FR3.6-16, FR3.6-17), добавлено 2 новых вопроса — OQ3.6-16, OQ3.6-17 (итого вопросов в разделе — 17). Подробности и список вопросов, которые по текущему коду выглядят закрытыми, но текст которых мы не трогаем, — в3.6-weblk.changes.md.
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| #OQ3.6-1 | Ветки релиза | Проблема: раздел собран в двух ветках кабинета, и они несовместимы между собой. Ветка WebLk-3.6-refactor (10.08) зовёт роли и каталог прав у AbacService именами GetRoles/CreateRole/UpdateRole/ArchiveRole — в ABAC эти методы называются GetPartnerRoles/CreatePartnerRole/UpdatePartnerRole/ArchivePartnerRole, а под привычными именами их выставляет наружу identity. Кроме того эта ветка не распаковывает обёртки ответа ({roles}, {employees}, {permissions}), ждёт код права строкой (бэк отдаёт объектом {domain, category, group, type}), шлёт ArchiveRole без partnerZoneId и зовёт словарь подписей как CmsService.GetPermissionLabels (на бэке метод называется GetPermissionDictionary). Ветка partner-zones-format-stg-athena (22.08) все эти расхождения уже закрывает — сверка ниже сделана по ней.Обновление 04.09.26: раздел уехал дальше — в employee-invite-sms-stg-athena, которая продолжает ту же линию и включает всё из athena-ветки. Сверка ниже пересобрана по ней. Вывод про WebLk-3.6-refactor не изменился. \ shared.fsd/api/role/role.api.ts (WebLk-3.6-refactor: AbacService + GetRoles) \ entities.fsd/role/model/useRoleMutations.ts (там же: архивация без partnerZoneId) \ shared.fsd/api/permission/permission.contracts.ts (там же: code строкой) \ shared.fsd/api/permission-label/permissionLabel.api.ts (там же: GetPermissionLabels) | Разработка | Open | Лить линию athena → employee-invite-sms-stg-athena. Ветку WebLk-3.6-refactor не мержить как есть: с текущим бэком раздел не поднимется (роли и каталог прав не загрузятся). Если из неё нужны какие-то правки — переносить точечно поверх. | |
| #OQ3.6-2 | Ветка бэкенда | Уточнение: abac_dev-stg-athena и abac-permission-code-object — это один и тот же коммит 070763bc, то есть стенд athena крутит ровно тот бэкенд, по которому сделана сверка; отдельную ветку выкатывать не нужно. Настоящая развилка в другом: этот бэкенд ещё не влит в основную линию — MR abac_dev-stg-athena → stands-tst-eos заблокирован конфликтами в 12 файлах booking.authentication (6 из них — [Obsolete("unused")], добавленный в main к методам, которые ветка удалила; остальные 6 — 14 блоков, где сходятся доработки back-1.1/1.3 и статус-коды из main с новой моделью ролей из athena). Пока конфликты не разрулены, раздел живёт только на стенде athena.Обновление 04.09.26: бэкенд раздела теперь employee-invite-sms-stg-athena @ 2c30bf6d — 22 коммита поверх main. Вопрос о вливании в основную линию остаётся, состав конфликтов нужно пересчитать заново. | Разработка | Open | Влить main в ветку merge-ом (не rebase), разрулить конфликты один раз и запушить — после этого MR в tst становится чистым. Новая тестовая ветка от main конфликты не убирает. | |
| #OQ3.6-3 | Код FR3.6-19 | Требование говорит: после сохранения сотрудник без действующего аккаунта отображается в группе «Приглашенные», а после первого входа переходит в группу «Активные» с активной иконкой и обновленными данными. В коде по последней сверке: активность включается при подтверждении email, а не после первого входа. | Разработка | Open | Привести переход в «Активные» к FR3.6-19: выполнять его после первого входа сотрудника и обновлять данные карточки. | Целевое поведение зафиксировано в FR3.6-19; требуется доработка реализации. |
| #OQ3.6-4 | Код FR3.6-11, FR3.6-15, FR3.6-18, FR3.6-20 | Требование говорит: после ввода обязательного телефона интерфейс ищет аккаунт сотрудника и определяет сценарий входа; действие называется «Сохранить»; для действующего аккаунта показывается уведомление об отправке инструкции на почту; инструкция отправляется по правилам FR3.6-20. В коде по последней сверке: форма до сохранения не ищет аккаунт, бэкенд определяет сценарий только при сохранении, а кабинет не читает из ответа канал и адрес доставки приглашения. \ features.fsd/employee-management/ui/EmployeeManagementForm.vue \ PartnerZoneEmployees/Commands/CreatePartnerZoneEmployee/CreateEmployeeResponse.cs | Разработка | Open | Добавить поиск аккаунта после ввода телефона, оставить единое действие «Сохранить», после сохранения показывать уведомление и отправлять инструкции по сценариям FR3.6-20. Тексты сообщений будут уточнены отдельно. | |
| #OQ3.6-5 | Код FR3.6-9, FR3.6-14 | Требование говорит: добавление сотрудника начинается из выбранной роли — панель роли раскрывается, «+» добавляет именно в эту роль, форма подставляет её в поле «Роль», а пункт «Добавить роль» в этом поле уводит в сценарий создания роли. В коде «+» живёт в общей панели над карточками и открывает пустую форму: выбранная слева роль в неё не передаётся, поле «Роль» открывается пустым, а пункта «Добавить роль» в списке ролей формы нет вовсе — роль заводится только кнопкой в левой панели раздела. \ widgets.fsd/employees-dashboard/ui/EmployeesDashboard.vue \ features.fsd/employee-management/ui/EmployeeManagementForm.vue | Разработка | Open | Завести тикет: передавать выбранную роль в форму добавления и подставлять её в поле «Роль»; добавить в это поле пункт «Добавить роль», открывающий панель создания роли и возвращающий партнёра в форму сотрудника с уже выбранной новой ролью. | |
| #OQ3.6-6 | Код FR3.6-21, FR3.6-25, FR3.6-32, FR3.6-33 | Требование говорит: партнер переходит к настройке роли и может удалить ее, только если в роли нет действующих сотрудников; настройки можно сохранить или отменить. В коде по последней сверке: удаление находится внутри панели роли, но условие отсутствия действующих сотрудников отдельно не подтверждено; «Готово» только закрывает режим настройки. Изменение порядка ролей по FR3.6-31 вынесено на будущую реализацию с весом 3. \ widgets.fsd/employees-dashboard/ui/EmployeesRolesSidebar.vue \ features.fsd/role-management/ui/RoleManagementForm.vue | Бизнес | Open | Проверить и при необходимости добавить запрет удаления роли с действующими сотрудниками. Изменение порядка ролей не включать в текущий релиз. | |
| #OQ3.6-7 | Код (снятый сценарий фотографии) | Проблема была закрыта удалением блока «Фото» из формы. Требование о загрузке фотографии удалено, а FR3.6-35 больше не содержит фотографию и разрешает изменять только объекты и роль сотрудника. В коде формы остаются неиспользуемые части прежней загрузки фотографии. \ features.fsd/employee-management/ui/EmployeeManagementForm.vue | Разработка | Closed | Убрать мёртвый код загрузки фотографии из формы отдельной технической задачей. | Блок «Фото» и требование о его использовании удалены из BRD. |
| #OQ3.6-8 | Код FR3.6-52 | Требование говорит: партнёр без права редактирования видит поля сотрудника в режиме просмотра, без действия сохранения. В коде (24.08) режим просмотра включался только для архивного сотрудника, а прав текущего пользователя кабинет не знал вообще. Обновление 04.09.26 — наполовину закрыто. Снимок прав в кабинете появился: раздел спрашивает у него разрешения на заведение, правку, архивацию и восстановление сотрудника и на работу с ролями и по ним скрывает действия. Осталась вторая половина требования: поля формы в режим просмотра по правам по-прежнему не переводятся — единственный источник readonly это архивность сотрудника. Партнёр без права правки видит обычные поля ввода, но кнопки сохранения у него нет. \ features.fsd/employee-management/ui/EmployeeManagementForm.vue \ entities.fsd/my-permissions/model/my-permissions.store.ts | Разработка | Open | Довести до конца: переводить поля в режим просмотра, когда права на правку нет. Снимок прав для этого уже есть — отдельного источника правды заводить не нужно. | |
| #OQ3.6-9 | Код FR3.6-34, FR3.6-38 | Проблема: две мелочи в редактировании сотрудника. Выбранная карточка визуально не выделяется — панель открывается, но в списке не видно, чей именно сотрудник правится. И кнопка сохранения активна сразу, как только форма валидна, а не после изменения данных: партнёр может открыть карточку и нажать «Сохранить», ничего не поменяв. \ widgets.fsd/employees-dashboard/ui/EmployeesDashboard.vue \ features.fsd/employee-management/ui/EmployeeManagementForm.vue | Разработка | Open | Завести тикет (мелкий): подсвечивать карточку открытого сотрудника и блокировать сохранение, пока форма не изменена (meta.dirty уже есть в форме). | |
| #OQ3.6-10 | Код FR3.6-54 | Требование говорит: раздел адаптируется под desktop, laptop, tablet и mobile. В коде во всём разделе один брейкпоинт — на ширине до 767 пикселей в дашборде; в панелях добавления сотрудника и настройки доступа роли адаптивных правил нет вовсе, а таблица прав уезжает в горизонтальную прокрутку. \ widgets.fsd/employees-dashboard/ui/EmployeesDashboard.vue | Разработка | Open | Проверить раздел на планшете и телефоне до релиза и завести тикет по найденному. Если tablet и mobile для раздела не в приоритете — понизить вес FR3.6-54 и зафиксировать поддерживаемые разрешения в BRD. | |
| #OQ3.6-11 | Код FR3.6-1 | Требование говорит: раздел показывает выбранную партнёрскую зону. В коде в шапке раздела стоит селектор объектов и площадок зоны (он же фильтр списка сотрудников), а сама зона в разделе не подписана — она выбирается в общем тулбаре кабинета. Формально требование выполняется всем остальным составом, кроме подписи зоны. \ widgets.fsd/employees-dashboard/ui/EmployeesDashboard.vue | Бизнес | Open | (А) считать показ зоны в общем тулбаре достаточным и уточнить формулировку FR3.6-1 (рекоменд., правок кода не требует). (Б) выводить название зоны в шапке раздела. | |
| #OQ3.6-12 | Код FR3.6-44 — FR3.6-47 | Что нашли (вес 3, на будущую реализацию): сценария S8 «Удаление сотрудника» нет ни на фронте, ни на бэке — ни действия «Удалить» в панели архивированного сотрудника, ни соответствующей ручки в identity. Есть только архивация и восстановление. Также не реализовано пустое состояние роли из FR3.6-47: вместо описания роли и действий показывается общий текст «Сотрудники не найдены». \ features.fsd/employee-management/ui/EmployeeManagementForm.vue \ shared.fsd/api/employee/employee.api.ts | Разработка | Open | До текущего релиза доработка не требуется. При будущей реализации учесть, что удаление в интерфейсе по BRD визуальное: для сервиса сотрудник остается в архиве, поэтому достаточно фронтового скрытия и пустого состояния роли. | |
| #OQ3.6-13 | Код FR3.6-5 | Требование говорит: партнёр ищет сотрудника по ФИО. В коде поиск фильтрует карточки по имени, а у приглашённого имени нет до тех пор, пока он не назовёт себя сам. Приглашённых в списке может быть много, и найти конкретного нельзя ничем: единственное, что владелец зоны о нём знает, — номер телефона, а по номеру поиск не работает. Расхождение появилось вместе с приглашением по одному номеру: раньше имя вводил владелец, и оно было всегда. \ widgets.fsd/employees-dashboard/ui/EmployeesDashboard.vue | Разработка | Open | Завести тикет: искать и по номеру телефона, не только по ФИО. Поле поиска оставить одно — распознавать ввод по формату, как это сделано на входе в кабинет. | |
| #OQ3.6-14 | Код FR3.6-16 | Что нашли: бэкенд отклоняет приглашение на номер архивного аккаунта отдельным сообщением — «человек восстанавливает аккаунт сам, зарегистрировавшись заново». Как этот отказ выглядит в кабинете, не проверено: отдельной обработки у формы нет, значит показывается общий текст ошибки сохранения. Заодно: сам текст отказа намеренно не раскрывает, чей это номер, — иначе владелец зоны узнавал бы о существовании чужой архивной учётной записи. \ PartnerZoneEmployees/Commands/CreatePartnerZoneEmployee/CreateEmployeeCommandHandler.cs | Бизнес | Open | Проверить отказ на стенде и согласовать с бизнесом текст, который увидит владелец зоны. Связано с Back: 1.1 OQ1.1-12 — там тот же вопрос со стороны системы. | |
| #OQ3.6-15 | Код FR3.6-18, FR3.6-20 | Что нашли: бэкенд возвращает запись сотрудника, канал доставки приглашения и адрес, а кабинет объявляет ответ плоской записью сотрудника. Из-за расхождения кабинет не может корректно использовать канал и адрес для уведомления по FR3.6-18 и сценариев отправки по FR3.6-20. \ shared.fsd/api/employee/employee.api.ts \ PartnerZoneEmployees/Commands/CreatePartnerZoneEmployee/CreateEmployeeResponse.cs | Разработка | Open | Привести тип ответа в кабинете к контракту бэкенда и использовать канал и адрес доставки совместно с OQ3.6-4. | |
| #OQ3.6-16 | Код FR3.6-6 | Требование говорит: у приглашённого сотрудника, который ещё не назвал себя, имя и email пустые — на их месте карточка показывает прочерк. В коде прочерк работает только в панели редактирования сотрудника: там пустые email и телефон рендерятся через props.employee?.email || '—'. В самой карточке списка — там, где требование как раз и просит показывать прочерк, — фолбэка нет: fullName в EmployeeShortCard.vue и email в EmployeeFullCard.vue попадают в шаблон как есть, и при пустых значениях поля рендерятся просто пустой строкой, без каких-либо символов на их месте. \ entities.fsd/employee/ui/EmployeeShortCard.vue:32 ({{ employee.fullName }}) \ entities.fsd/employee/ui/EmployeeFullCard.vue:28 ({{ employee.email }}) \ widgets.fsd/employees-dashboard/lib/mapEmployeeToFullCardData.ts:19 (fullName без фолбэка) \ для сравнения: features.fsd/employee-management/ui/EmployeeManagementForm.vue:264,270 (прочерк есть, но только в форме правки) | Разработка | Open | Завести тикет: добавить фолбэк «—» для пустых fullName и email в EmployeeShortCard.vue/EmployeeFullCard.vue (и в mapEmployeeToFullCardData.ts, если фолбэк удобнее ставить на маппинге), аналогично тому, что уже сделано в панели редактирования. | |
| #OQ3.6-17 | Код FR3.6-28, FR3.6-13 | Требование говорит: признака доступа ко всем объектам у роли нет — он принадлежит только сотруднику, а не роли: «роль общая на всех, кому она выдана, и сказать ею про конкретного человека нельзя» (см. «Ключевые понятия»). В коде у роли есть собственное поле hasAllBases: оно приходит в RoleDto, задаётся при создании и правке роли через CreateRolePayload/UpdateRolePayload, хранится на бэке в PartnerRoleDto и командах роли, а форма роли показывает чекбокс «Доступ ко всем объектам зоны» с пояснением «Сотрудник с этой ролью работает во всех объектах зоны, а не только в выданных ему». Это отдельный флаг от hasAllBases сотрудника (Employee.hasAllBases, CreateEmployeeCommand.HasAllBases) — в системе сейчас два независимых признака «доступ ко всем объектам»: у роли и у сотрудника, и как они соотносятся, если расходятся (например, у роли включено, у сотрудника выключено), нигде не описано и не проверено. \ shared.fsd/api/role/role.contracts.ts:18,38 (hasAllBases в RoleDto/CreateRolePayload) \ features.fsd/role-management/ui/RoleManagementForm.vue:181-190 (чекбокс в форме роли) \ Authentication.Application/PartnerRoles/PartnerRoleDto.cs:17 (HasAllBases) \ Authentication.Application/PartnerRoles/ManageRoles/RoleCommands.cs:21,37,79,107,136 | Бизнес | Open | (А) признать признак у роли осознанным расширением (роль-шаблон «работает везде») и обновить FR3.6-28 и «Ключевые понятия», прописав, как соотносятся флаг роли и флаг сотрудника, если они расходятся. (Б) убрать hasAllBases с роли и оставить признак только у сотрудника, как написано в BRD сейчас. Выбор влияет на форму роли и контракты CreateRolePayload/UpdateRolePayload. |