Направление работ: WebLK Код раздела: 1.1 Авторизация > Регистрация партнера Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 08.06.26
1. Назначение
Раздел описывает функциональные требования к регистрации партнера в веб-интерфейсе партнерской зоны МАРТ.
Интерфейс должен провести пользователя от ввода регистрационных данных до подтверждения телефона, подтверждения email, ввода информации о компании и перехода к следующему шагу настройки партнерской зоны.
Раздел зависит от:
- Back: 1.1 Организация аккаунтов
- Back: 1.1.1 Регистрация
- Back: 1.2 Организация доступа к системе
2. Ключевые понятия
Регистрация партнера — пользовательский сценарий создания Аккаунта и запуска доступа к партнерской зоне через веб-интерфейс.
SMS-код — 4-значный код подтверждения владения номером телефона.
Email-код — 6-значный код подтверждения владения адресом электронной почты.
Информация о компании — данные, которые пользователь вводит после подтверждения учетных данных для продолжения настройки партнерской зоны.
Соглашение — набор пользовательских документов, согласие с которыми фиксируется при запуске процесса регистрации.
3. Scope
Входит
- Запуск регистрации партнера в партнерской зоне
- Ввод персональных данных, email, телефона, пароля и подтверждения пароля
- Отображение и открытие пользовательских документов
- Отправка учетных данных и запуск подтверждения
- Ввод, проверка и повторная отправка SMS/Email-кода
- Ввод информации о компании
- Переход к следующему шагу после успешной регистрации
- Состояния интерфейса и ошибки регистрации
Не входит
- WebLK: 1.2 Вход
- WebLK: 1.3 Восстановление доступа
- Настройки партнерской зоны?? (Не утверждено)
- WebLk: 4.1 Создание и настройка объектов партнера
- Back: 7.1 Шаблоны SMS/email-уведомлений и правила их доставки
- Backend-логика создания Аккаунта, токенов и прав доступа
4. BR
Бизнес-правила и ограничения указаны в Back: 1.1 Организация аккаунтов, Back: 1.1.1 Регистрация.
5. Функциональные требования (UC + FR)
FR – functional requirements, что интерфейс должен уметь делать по определенному UC (триггеру).
| ID | Сценарий | Функциональное требование | BR | Статус |
|---|---|---|---|---|
| FR-1 | Пользователь открывает регистрацию и вводит регистрационные данные | Интерфейс открывает старт регистрации партнера и показывает поля: имя, фамилия, Email, телефон, пароль и подтверждение пароля. Принимает данные, применяя формат полей и скрывает пароль по умолчанию. | Back: 1.1.1 | Реализовано |
| FR-2 | Пользователь открывает пользовательские документы | Интерфейс позволяет открыть правила сервиса и политику конфиденциальности из текста согласия, а затем вернуться к регистрации без потери введенных данных. | Back: 1.1.1 | Не реализовано, OQ-4 |
| FR-3 | Пользователь видит ошибки стартовой формы | Интерфейс показывает ошибки по полям: недопустимые символы в имени/фамилии, некорректный email, неверный формат телефона, несовпадение паролей или ошибку с Back. | Back: 1.1; Back: 1.1.1 | Реализовано |
| FR-4 | Пользователь отправляет регистрационные данные | Интерфейс активирует продолжение после заполнения обязательных полей и отправляет регистрационные данные, источник и факт согласия с условиями. | Back: 1.1.1 | Частично, OQ-5 |
| FR-5 | Пользователь попадает на подтверждение телефона | Интерфейс показывает номер, на который отправлен SMS-код, поле ввода 4 цифр и таймер до возможности запросить новый код. | Back: 1.1; Back: 1.1.1 | Частично, OQ-6 |
| FR-6 | Пользователь вводит SMS-код | Код подтвержден: пользователь автоматически переводится к подтверждению email. Код не подтвержден: интерфейс показывает ошибку неверного, устаревшего или временно заблокированного кода и позволяет повторить ввод или запросить новый код после доступности действия. | Back: 1.1; Back: 1.1.1 | Частично, OQ-7 |
| FR-7 | Пользователь попадает на подтверждение email | Интерфейс показывает email, на который отправлен код, поле ввода 6 цифр и таймер до возможности запросить новый код. | Back: 1.1; Back: 1.1.1 | Не реализовано, OQ-7 |
| FR-8 | Пользователь вводит email-код | Код подтвержден: пользователь переходит к вводу информации о компании. Код не подтвержден: интерфейс показывает ошибку неверного или устаревшего кода и позволяет повторить ввод или запросить новый код после таймера. | Back: 1.1; Back: 1.1.1 | Не реализовано, OQ-7 |
| FR-9 | Пользователь вводит информацию о компании | Интерфейс принимает название компании и сайт/публичную страницу, применяет проверки формата и не отправляет данные, пока обязательные поля шага не заполнены корректно. | — | Частично, OQ-8 |
| FR-10 | Пользователь некорректно ввел информацию о компании | Интерфейс показывает ошибку недопустимых символов в названии компании или некорректной ссылки и позволяет исправить данные без возврата на предыдущие шаги. | — | Частично, OQ-8 |
| FR-11 | Регистрация завершена успешно | Интерфейс завершает регистрацию партнера и переводит пользователя к следующему продуктовому сценарию. К КАКОМУ (какой-то из этих?): 3.1 — Профиль партнёра > Главный экран 3.3 — Профиль партнёра > Основные настройки ? | Back: 1.1.1; | Реализовано, OQ-9 |
| FR-12 | Возникла ошибка соединения или техническая ошибка | Интерфейс показывает ошибку, сохраняет введенные данные текущего шага и позволяет повторить действие без дублирования запроса. | — | Частично, OQ-10 |
6. Открытые вопросы
BRD 1.1 v0.1 · musbooking_personal_account · commit cdfa1dad1874864b3317ce7cb4e989f7e6ed6e5d / origin/main (2026-09-07) · 2026-09-08 · повторная сверка по итогам дейликов · якорь:
features.fsd/auth-registration/,features.fsd/partner-registration/,pages/auth/registration.vue,pages/auth/partner-registration.vue,pages/auth/verify-code/[phone].vue,pages/auth/email-confirmation.vue,shared.fsd/api/auth/,shared.fsd/validation-schemes/auth-schemes.tsСводка: новых вопросов 7 (Open 6: Разработка 5 / Бизнес 1 · Подтверждено 1) · существующих открытых вопросов не тронуто: 2 (OQ-1, OQ-3) · статусов изменено: 12 из 12 (были пустые) · обратный проход: без отдельных находок сверх покрытых вопросами выше (проверка уникальности email/телефона на blur — расширение сверх BRD, не требует вопроса) Маршрутизация без сверки с гайдбуком (гайдбук не передан).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ-1 | Лайза | Будет ли подтверждение email обязательным именно на этапе регистрации партнерской зоны? Обязательное подтверждение на и без того длительной регистрации на мой и Никитины взгляды усложняет путь, увеличивает число действий и вынуждает снова переходить в сторонние ресурсы, повышая нагрузку на пользователя и потенциально снижающая конверсию в завершение реги. Как альтернатива – подсветить пользователю, что без подтвержденного имейл часть функционала не доступна, но оставить возможность выбора “Подтвердить позднее” (в настройках) | Герман | Open | ||
| OQ-3 | Лайза | Какой точный раздел открывается после успешной регистрации: Настройки? | Герман | Open | ||
| OQ-4 | Код FR-2 | Требование говорит: из текста согласия можно открыть правила сервиса и политику конфиденциальности, а затем вернуться к регистрации без потери данных. В коде ссылки «правилами» и «политикой конфиденциальности» никуда не ведут — это неактивные ссылки без адреса, клик по ним ничего не делает. \ RegistrationForm.vue:98-104 | Разработка | Open | Завести тикет в Bitrix: проставить ссылки на документы правил сервиса и политики конфиденциальности в форме регистрации. | |
| OQ-5 | Код FR-4 | Требование говорит: вместе с регистрационными данными интерфейс отправляет источник регистрации и факт согласия с условиями. В коде оба поля отсутствуют: в данных, которые уходят на сервер, нет ни источника, ни отдельного признака согласия — согласие выражено только текстом рядом с кнопкой, без сохраняемого значения. \ shared.fsd/api/auth/auth.types.ts:87-97 (RegisterData), RegistrationForm.vue:154-178 | Разработка | Open | (А) добавить поля источника и согласия в форму/запрос — на случай, если аналитика или юридическое подтверждение согласия действительно нужны отдельным полем (Б, рекомендуется) уточнить у бизнеса, нужны ли эти поля вообще, прежде чем реализовывать: возможно, это устаревшая формулировка BRD. | |
| OQ-6 | Код FR-5 | Требование говорит: пользователь вводит 4-значный SMS-код. В коде поле подтверждения телефона рассчитано на 6 цифр (тот же размер, что и у email-кода), а не на 4, как в требовании и в определении термина «SMS-код». \ features.fsd/auth-registration/ui/SmsConfirmation.vue:59 | Разработка | Open | (А, рекомендуется) привести BRD к коду — зафиксировать 6 цифр, если так и должно быть по факту работы SMS-провайдера (Б) привести код к BRD, если 4 цифры — осознанное продуктовое решение. | |
| OQ-7 | Код FR-6, FR-7, FR-8 | Требование говорит: после успешного ввода SMS-кода пользователь автоматически переходит к подтверждению email (экран с полем на 6 цифр и таймером), и только после него — к вводу информации о компании. В коде после подтверждения телефона пользователь сразу попадает на экран ввода информации о компании — шаг подтверждения email в сценарии регистрации партнёра отсутствует полностью: экран pages/auth/email-confirmation.vue в этом сценарии не используется вовсе. Это прямо пересекается с вопросом OQ-1 о том, нужно ли вообще обязательное подтверждение email при регистрации — судя по коду, решение уже принято в пользу «не требовать». \ pages/auth/verify-code/[phone].vue:42-44 | Бизнес | Open | Связать с OQ-1: если бизнес подтверждает, что email на регистрации подтверждать не нужно — снять FR-7/FR-8 из обязательного скоупа и обновить формулировку BRD; если подтверждение обязательно — заводить отдельную задачу на разработку (шаг сейчас отсутствует, хотя переиспользуемые компоненты для него уже есть в кабинете сотрудника). | |
| OQ-8 | Код FR-9, FR-10 | Требование говорит: интерфейс проверяет формат названия компании и ссылки и показывает ошибку недопустимых символов в названии компании. В коде для названия компании проверяются только обязательность и длина (2–255 символов), проверки на недопустимые символы нет; для ссылки формат и часть символов проверяются. \ features.fsd/partner-registration/lib/schema.ts:12-16 | Разработка | Open | Завести тикет в Bitrix: добавить проверку допустимых символов в названии компании, если бизнес подтвердит, что такое ограничение нужно. | |
| OQ-9 | Код FR-11 | Что подтверждено: после создания партнёрской зоны интерфейс не переводит на отдельный экран настроек, а переходит на корневой маршрут кабинета (/) — то есть на главный экран профиля партнёра, а не в «Основные настройки». Это отвечает на открытый вопрос OQ-3 о том, какой раздел открывается после регистрации. \ pages/auth/partner-registration.vue:13-15, app.fsd/session/completeAuthorizedSession.ts:37,57-84, shared.fsd/config/routes/pageRoutes.ts:4 | — | Подтверждено | Расхождения с ожиданием «главный экран» нет; рекомендуем сверить с OQ-3 и закрыть его этим фактом. | — |
| OQ-10 | Код FR-12 | Требование говорит: при ошибке соединения или технической ошибке интерфейс показывает сообщение, сохраняет данные текущего шага и позволяет повторить действие без дублирования запроса. В коде это верно для стартовой формы регистрации (данные не сбрасываются, повтор блокируется на время отправки), но на шаге ввода информации о компании отправка не обёрнута в обработку ошибок вовсе: при сетевой/технической ошибке пользователь не увидит сообщения об ошибке. \ features.fsd/partner-registration/ui/PartnerRegistrationForm.vue:73-81 | Разработка | Open | Завести тикет в Bitrix: добавить обработку ошибок (try/catch + сообщение пользователю) в форму информации о компании по аналогии со стартовой формой регистрации. |