Направление работ: WebLK Код раздела: 1.2 Авторизация > Вход Статус: черновик Ответственный: Панкова Л.А. Версия: 0.2 Обновлено: 04.09.26
1. Назначение
Раздел описывает функциональные требования к входу пользователя в веб-интерфейс партнерской зоны МАРТ.
Интерфейс должен провести пользователя от ввода идентификационных данных и пароля до выбора доступной партнерской зоны и перехода в релевантный продуктовый сценарий. Если сотрудник партнера впервые входит по приглашению, интерфейс должен провести его через дозаполнение профиля и подтверждение email до продолжения входа: до этого кабинет ему закрыт.
Раздел зависит от Back: 1.1 Организация аккаунтов, Back: 1.1.2 Вход в систему и Back: 1.2 Организация доступа к системе.
2. Ключевые понятия
Вход в партнерскую зону — пользовательский сценарий доступа в веб-интерфейс партнерской зоны по учетным данным Аккаунта.
Идентификационные данные — телефон или подтвержденный email, которые пользователь указывает при входе.
Роль (?) для входа — доступная пользователю партнерская зона и роль, которую он выбирает после успешной проверки учетных данных.
Партнерская зона — область WebLK, в рамках которой пользователь работает с объектами, площадками, бронированиями и операционными данными.
Первый вход сотрудника партнера — вход Аккаунта, который был приглашен владельцем партнерской зоны и получил временный пароль по SMS. Такой вход подтверждает номер телефона, но Приглашение не завершает.
Дозаполнение профиля — промежуточный шаг входа, на котором приглашенный указывает имя, фамилию и email и подтверждает email кодом. До его завершения кабинет закрыт: токен несет назначение «онбординг», и все методы, кроме дозаполнения, отклоняются.
Состояние Аккаунта — значение, которое интерфейс получает от системы готовым и по которому решает, куда вести пользователя: в регистрацию, на дозаполнение профиля или в кабинет. Собирать состояние на стороне кабинета не следует — см. Back: 1.1.
Разлогин — выход пользователя из текущей авторизованной сессии партнерской зоны для смены аккаунта.
3. Scope
Входит
- Открытие страницы входа в партнерскую зону
- Ввод идентификационных данных и пароля
- Отправка данных для входа
- Обработка успешного входа
- Дозаполнение профиля и подтверждение email при первом входе сотрудника партнера по приглашению
- Выбор партнерской зоны и роли для входа
- Переход в выбранную партнерскую зону или в настройки
- Создание новой партнерской зоны из выбора аккаунта
- Разлогин из состояния выбора аккаунта
- Состояния ошибок входа и соединения
- Адаптивные состояния страницы входа
Не входит
- WebLK: 1.1 Авторизация > Регистрация партнера
- WebLK: 1.3 Авторизация > Восстановление пароля
- WebLk: 3.3 Профиль партнера > Основные настройки
- WebLK 3.1 Профиль партнера > Главный экран
4. BR
Бизнес-правила и ограничения указаны в Back: 1.1 Организация аккаунтов, Back: 1.1.2 Вход в систему и Back: 1.2 Организация доступа к системе.
5. Функциональные требования (UC + FR)
FR – functional requirements, что интерфейс должен уметь делать по определенному UC (триггеру).
| ID | Сценарий | Функциональное требование | BR | Статус |
|---|---|---|---|---|
| FR-1 | Пользователь открывает вход | Интерфейс открывает страницу входа и показывает поля идентификационных данных и пароля, а также действия перехода к регистрации и восстановлению пароля. | Back: 1.1; Back: 1.1.2 | Реализовано |
| FR-2 | Пользователь вводит идентификационные данные | Интерфейс принимает телефон или email в одном сценарии входа, применяет формат поля и позволяет продолжить только после заполнения обязательных данных. | Back: 1.1.2 | Частично, OQ-11 |
| FR-3 | Пользователь вводит пароль | Интерфейс принимает пароль, скрывает введенное значение по умолчанию и позволяет управлять видимостью пароля. | Back: 1.1.2 | Реализовано |
| FR-4 | Пользователь отправляет данные для входа | Интерфейс отправляет выбранный идентификатор и пароль на проверку, предотвращает повторную отправку до ответа. | Back: 1.1; Back: 1.1.2 | Реализовано |
| FR-5 | Вход выполнен успешно | Интерфейс обрабатывает успешный ответ и по состоянию Аккаунта переводит пользователя к следующему сценарию: на дозаполнение профиля — в состояниях S2 и S4, к выбору роли — в S5, в регистрацию партнерской зоны — в S3. Архивный Аккаунт (S6) в кабинет не допускается. | Back: 1.1; Back: 1.1.2; Back: 1.2 | Частично, OQ-9, OQ-10 |
| FR-6 | Сотрудник партнера дозаполняет профиль при первом входе | Интерфейс показывает шаг дозаполнения профиля после успешной проверки идентификатора и пароля, если Приглашение не завершено. На шаге запрашиваются имя, фамилия и email; заголовок сообщает, что данные нужны для завершения регистрации в кабинете партнера. Отдельного подтверждения номера телефона на этом шаге нет: номер подтвержден самим входом по временному паролю из приглашения. | Back: 1.1; Back: 1.1.2; Back: 1.2 | Реализовано |
| FR-6.1 | Сотрудник партнера подтверждает email | После сохранения данных профиля интерфейс показывает шаг ввода кода, отправленного на указанный email, с возможностью запросить код повторно по таймеру. Приглашение завершается именно подтверждением email: до него назначенные роли не действуют и кабинет закрыт. После успешной проверки кода интерфейс продолжает вход и переводит пользователя к выбору роли. | Back: 1.1; Back: 1.1.2 | Частично, OQ-8 |
| FR-7 | Пользователь выбирает роль для входа | Интерфейс показывает доступные партнерские зоны с ролью пользователя и позволяет выбрать один вариант для продолжения, а также возможность *создать новую зону или вернуться к авторизации для смены аккаунта. | Back: 1.2 | Не реализовано, OQ-9 |
| FR-8 | Пользователь переходит после выбора роли | Интерфейс переводит пользователя в настройки, если настройка ранее не завершена, или в главный экран профиля партнера, если зона готова к работе. | Back: 1.2 | Не реализовано, OQ-12 |
| FR-9 | *Пользователь создает новую партнерскую зону | *Не войдет в текущую реализацию. Интерфейс позволяет перейти из списка аккаунтов к созданию новой партнерской зоны без повторного ввода учетных данных. | Back: 1.1.1; Back: 1.2 | Не реализовано |
| FR-10 | Пользователь ввел неверные данные | Интерфейс показывает единую ошибку входа без уточнения, какое поле неверно, и позволяет исправить идентификатор или пароль. | Back: 1.1.2 | Реализовано |
| FR-11 | Возникла ошибка соединения или техническая ошибка | Интерфейс показывает ошибку, сохраняет введенные идентификационные данные и позволяет повторить действие после восстановления соединения. | — | Реализовано |
6. Открытые вопросы
BRD 1.2 v0.2 · musbooking_personal_account · commit cdfa1dad1874864b3317ce7cb4e989f7e6ed6e5d / origin/main (2026-09-07) · 2026-09-08 · повторная сверка по итогам дейликов · якорь:
features.fsd/auth-login/,features.fsd/profile-completion/,features.fsd/change-partner-zone/,entities.fsd/partner-zone/,app.fsd/,pages/auth/authorization.vue,pages/auth/profile-completion.vue,pages/auth/email-confirmation.vue,shared.fsd/api/auth/,middleware/auth.global.tsСводка: новых вопросов 6 (Open 5: Разработка 3 / Бизнес 2 · Подтверждено 1) · существующих открытых вопросов не тронуто: 5 (OQ-1, OQ-3, OQ-4, OQ-5, OQ-6 — по коду OQ-4 выглядит закрытым, OQ-5 и OQ-6 частично продвинуты, см. OQ-7/OQ-8/OQ-10) · статусов изменено: 12 из 12 (10 из «To Do»/пусто, 2 обновлены по факту кода — FR-5, FR-6, FR-6.1) · обратный проход: без отдельных находок сверх покрытых вопросами выше Маршрутизация без сверки с гайдбуком (гайдбук не передан).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ-1 | Лайза / Денис | Как называется вариация выбора партнерской зоны для пользователя – выбор аккаунта / роли? | Герман | Open | ||
| OQ-3 | Лайза / Никита | Нужно ли поддерживать вход по логину/публичному имени для партнерской зоны при миграции, или WebLK использует только телефон и email? (Открытый вопрос на стендап, такой же как в Back 1.1.2 | Герман / рук отд продаж | Open | ||
| OQ-4 | Код FR-5 | Требование говорит: после входа интерфейс ведет пользователя по состоянию Аккаунта. В коде нумерация состояний в кабинете сдвинута на единицу относительно системы: кабинет считает первое состояние нулевым, система — первым. Состояние приходит числом, поэтому S5 «полный профиль, есть зона» кабинет читает как «архивирован» и закрывает доступ с ошибкой, а архивный Аккаунт не распознает вовсе. |shared.fsd/api/auth/auth.types.ts:9,14 против AccountState.cs:23,65| | Разработка | Open | Привести перечисление в кабинете к системе: нумерация с единицы, шесть значений. До этого вход в кабинет не работает ни у кого. | Правим кабинет под бэк: S1 = 1 … S6 = 6. |
| OQ-5 | Код FR-6, FR-6.1 | Требование говорит: Приглашение завершается дозаполнением профиля и подтверждением email. В коде шаг дозаполнения есть и данные сохраняет, а шага подтверждения email нет вовсе: кабинет не вызывает ни отправку кода, ни его проверку. Приглашенный после сохранения данных попадает в кабинет, где каждый запрос отклоняется шлюзом, потому что токен остался онбординговым. |features.fsd/profile-completion/ui/ProfileCompletionForm.vue — только сохранение данных| | Разработка | Open | Добавить шаг ввода кода с email после сохранения профиля и обновлять сессию по его результату. Со стороны бэка нужен метод подтверждения, возвращающий полноценный токен, — Back: 1.1.2 OQ1.1.2-5. | Делаем оба конца: метод на бэке и шаг подтверждения в кабинете. |
| OQ-6 | Код FR-5 | Требование говорит: архивный Аккаунт в кабинет не допускается. В коде кабинет при таком состоянии бросает техническую ошибку инициализации сессии вместо человеческого сообщения — пользователь видит экран ошибки, а не объяснение, что учетная запись архивирована и как ее восстановить. |app.fsd/session/applyUserAccountAccess.ts| | Бизнес | Open | Показывать отдельный экран с объяснением и путем восстановления: восстановление идет повторной регистрацией тем же номером. Уточнить у бизнеса текст. | |
| OQ-7 | Код FR-5 | Что подтверждено: нумерация состояний аккаунта S1–S6 в кабинете больше не сдвинута относительно бэка — оба перечисления стартуют с единицы и совпадают по всем шести значениям; в коде кабинета появился явный комментарий, объясняющий, что нумерация с единицы — намеренное решение именно ради совпадения с бэком. Расхождение, из-за которого был открыт OQ-4, устранено. \ shared.fsd/api/auth/auth.types.ts:8-22 (кабинет) vs booking-monorepo: src/services/booking.authentication/src/Authentication.Domain/Accounts/StateMachine/AccountState.cs:28-79 (бэк) | — | Подтверждено | Расхождения нет, рекомендуем закрыть OQ-4 этим фактом. | — |
| OQ-8 | Код FR-6.1 | Требование говорит: после сохранения данных профиля интерфейс показывает шаг ввода кода с email с возможностью запросить код повторно по таймеру; после успешной проверки — переводит к выбору роли. В коде шаг подтверждения email появился и работает: код принимается, проверяется, и при успехе сервер меняет онбординговый токен на полноценный, после чего пользователь возвращается в общий сценарий входа. Но таймера и кнопки повторной отправки кода на этом шаге нет вовсе — форма содержит только поле ввода кода. А вместо «выбора роли» пользователь сразу попадает в кабинет с автоматически выбранной зоной, потому что отдельного экрана выбора роли в кабинете нет (см. OQ-9). \ features.fsd/profile-completion/ui/EmailConfirmationForm.vue:1-47 (нет таймера/повторной отправки), server/api/auth/verify-email-code-partner.post.ts:76-96 (обновление токена на полноценный) | Разработка | Open | Добавить таймер и повторную отправку кода на шаг подтверждения email — по аналогии с подтверждением SMS при регистрации (WebLk 1.1, SmsConfirmation.vue). Вопрос про экран выбора роли после подтверждения — см. OQ-9, здесь не дублируем. | |
| OQ-9 | Код FR-5, FR-7 | Требование говорит: пользователь с доступной партнерской зоной (в т.ч. несколькими) видит экран выбора зоны/роли после успешного входа — с возможностью выбрать вариант, создать новую зону или разлогиниться для смены аккаунта. В коде такого экрана нет вовсе: партнерская зона выбирается автоматически — либо ранее сохраненная в cookie, либо первая по списку ролей пользователя — без какого-либо подтверждения или выбора со стороны пользователя. По этому же пути проходит и приглашенный сотрудник сразу после подтверждения email (см. OQ-8). \ shared.fsd/lib/partner-zone/resolveCurrentPartnerZoneId.ts:30-41, app.fsd/session/completeAuthorizedSession.ts:17-33,57-84 | Бизнес | Open | (А) если пользователей с несколькими зонами на входе практически не бывает — осознанно оставить автовыбор первой/сохраненной зоны и снять формулировку «выбор роли» из BRD; (Б, рекомендуется, если зон у пользователя обычно несколько) — заказать в разработку отдельный экран выбора зоны/роли, которого сейчас нет вовсе. | |
| OQ-10 | Код FR-5 | Требование говорит: архивный Аккаунт (S6) в кабинет не допускается — см. также OQ-6. В коде сообщение об отказе зависит от пути входа: при обычном входе через форму пользователь видит понятный текст «Доступ к архивной учетной записи закрыт»; но при повторной инициализации уже открытого кабинета (например, обновление страницы) то же сообщение оборачивается в техническую фразу «На стадии инициализации произошла ошибка: …» и показывается как обычная страница ошибки Nuxt, а не как отдельный экран с объяснением, которого просит OQ-6. \ features.fsd/auth-login/ui/AuthLoginForm.vue:82-89 (человекочитаемый путь при входе), app.fsd/init/initApp.ts:79-87 и middleware/auth.global.ts:7-8 (технический путь при повторной инициализации) | Разработка | Open | Показывать один и тот же понятный экран независимо от пути: сейчас middleware/auth.global.ts:7-8 заворачивает уже готовое человекочитаемое сообщение в техническую обёртку. Работа продвинулась дальше, чем предполагал OQ-6, но полностью вопрос не закрыт. | |
| OQ-11 | Код FR-2 | Требование говорит: интерфейс позволяет продолжить только после заполнения обязательных данных. В коде кнопка «Продолжить» на форме входа блокируется только на время отправки запроса, а не по пустоте или неверному формату полей — нажать можно всегда, ошибка появится только после попытки отправки. \ features.fsd/auth-login/ui/AuthLoginForm.vue:39,71 | Разработка | Open | Завести тикет в Bitrix: завязать disabled кнопки на валидность формы (meta.valid), как уже сделано в ProfileCompletionForm.vue:37. | |
| OQ-12 | Код FR-8 | Требование говорит: после выбора роли интерфейс ведет в настройки, если настройка партнерской зоны ранее не завершена, или на главный экран, если зона готова к работе. В коде такого разделения нет — после входа пользователь всегда попадает на главный экран (/); признака «настройка зоны не завершена» в данных аккаунта или зоны в коде кабинета не найдено. \ app.fsd/session/completeAuthorizedSession.ts:37,57-84 (redirectTo по умолчанию — pageRoutes.home()) | Бизнес | Open | Уточнить, актуально ли ещё разделение «зона настроена / не настроена» на входе: если да — нужен признак готовности зоны и логика редиректа; если требование устарело (например, обязательная настройка зоны теперь идёт сразу при её создании, см. WebLk 1.1) — можно снять его из BRD. |