Направление работ: Mobile Код раздела: 5.2.1 Профиль > Настройки профиля > Редактирование учетных данных Статус: Готов Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 21.07.26
1. Назначение
Раздел описывает редактирование учетных данных пользователя в мобильном приложении.
Пользовательская цель: обновить личные данные, контактную информацию и дополнительные сведения о себе.
2. Ключевые понятия
Редактирование учетных данных - экран профиля, на котором пользователь изменяет личные данные, контактные данные, социальные сети и дополнительную информацию.
Настройки профиля - раздел мобильного приложения, из которого пользователь переходит к редактированию профиля.
Карточка клиента - сущность, в которой хранятся персональные данные пользователя.
Подтверждение контакта - ввод кода из SMS или письма для подтверждения нового телефона или email.
3. Scope
Входит
S1. Просмотр и редактирование учетных данных профиля.
S2. Смена номера телефона.
S3. Привязка или смена электронной почты.
S4. Ошибка валидации при вводе некорректного email.
Не входит
- Mobile 1.2 Регистрация - ввод кода из SMS.
- Mobile 1.2.2 Подтверждение почты - ввод кода из письма.
- Backend-логика подтверждения телефона и почты.
4. BR
Указаны в пункте 4 раздела Back: 1.3 Клиенты.
5. Функциональные требования (UC + FR)
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR5.2.1-1 | Пользователь открывает редактирование учетных данных из выпадающего меню профиля «Редактировать профиль» | Интерфейс позволяет перейти к редактированию учетных данных из выпадающего меню профиля по пункту «Редактировать профиль». В блоке «Контактные данные» по нажатию на телефон запускается сценарий смены номера телефона. В блоке «Контактные данные» по нажатию на почту запускается сценарий привязки или смены электронной почты. | 1 | Частично \ #OQ5.2.1-1 | |
| S2: FR5.2.1-2 | Пользователь выбирает смену номера телефона | Интерфейс открывает нижний лист без шапки. В теле нижнего листа отображаются заголовок «Укажите новый номер», текст «Мы отправим на него код подтверждения», поле ввода номера, кнопка «Продолжить» и цифровая клавиатура. | 1 | Реализовано | |
| S2: FR5.2.1-3 | Пользователь отправляет новый номер телефона на подтверждение | Интерфейс передает новый номер на подтверждение и переводит пользователя к вводу кода из SMS. После успешного подтверждения интерфейс возвращает пользователя на экран редактирования профиля и показывает уведомление «Номер телефона обновлен». | 1 | Частично \ #OQ5.2.1-2 | |
| S3: FR5.2.1-4 | Пользователь выбирает привязку или смену электронной почты | Интерфейс открывает нижний лист «Укажите новый адрес электронной почты» или «Укажите адрес электронной почты» с текстом «Мы вышлем код подтверждения», полем «Email» и кнопкой «Продолжить». Если email не введен, кнопка «Продолжить» недоступна. | 1 | Реализовано | |
| S3: FR5.2.1-5 | Пользователь отправляет email на подтверждение | Интерфейс передает email на подтверждение и переводит пользователя к вводу кода из письма. После успешного ввода и подтверждения почты кнопка «Продолжить» становится активной. После успешного подтверждения интерфейс возвращает пользователя на экран редактирования профиля и показывает уведомление «Электронная почта подтверждена» при первой привязке или «Электронная почта обновлена» при смене почты. | 1 | Частично \ #OQ5.2.1-2 | |
| S4: FR5.2.1-6 | Пользователь вводит email некорректного формата | Интерфейс показывает ошибку валидации «Некорректный email» под полем email и оставляет кнопку «Продолжить» недоступной. | 1 | Реализовано |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| #OQ5.2.1-1 | Код FR5.2.1-1 | Требование говорит: вход в редактирование учётных данных — из раздела 5.2 «Настройки профиля». В коде вход — из выпадающего меню шапки профиля («Редактировать профиль»); экран «Настройки» (ProfileSettingsScreen) ссылки на редактирование не содержит (там гео, смена пароля/код-пароля, удаление аккаунта). Клики по телефону/почте на самом экране редактирования сценарии открывают корректно. \ profile_title.dart:219,229-233; profile_settings_screen.dart:81-573; edit_profile_screen.dart:386-411,444-474 | Бизнес (Герман) | Closed | Расхождение в описанном пути. (А, рекоменд.) привести BRD/дизайн к факту — вход через меню шапки профиля, зафиксировать в FR5.2.1-1; (Б) если вход должен быть из «Настроек» — добавить пункт в ProfileSettingsScreen. Пересекается с 5.1/OQ5.1-4 и 5.2/OQ5.2-3 (то же меню «⋯»). | привести BRD/дизайн к факту — вход через меню шапки профиля, зафиксировать в FR5.2.1-1 Ок, поменяли формулировку. |
| #OQ5.2.1-2 | Код FR5.2.1-3, FR5.2.1-5 | Требование говорит: после отправки контакта — переход к вводу кода в разделах 1.2 / 1.2.2 (ввод кода вынесен в «Не входит»). В коде ввод кода реализован внутри той же модалки отдельной страницей ConfirmedPinPage (3-я страница PageView), со своими текстами и вызовами approveCodeUpdatePhoneMobile / approveCodeUpdateEmailMobile; переходов на 1.2 / 1.2.2 нет. \ check_email_phone_main.dart:65-88; confirmed_pin_page.dart:141-233; check_contacts_modal_cubit.dart:52-81 | Бизнес/Разработка | Closed | Две независимые реализации ввода кода (регистрация 1.2/1.2.2 и модалка смены контакта). (А, рекоменд.) узаконить in-modal ввод как отдельный сценарий и убрать из FR5.2.1-3/-5 ссылку на 1.2/1.2.2 (оставить её только как «Не входит: backend»); (Б) переиспользовать экраны 1.2/1.2.2 и удалить ConfirmedPinPage (меньше дублирования, но нужно прокидывать контекст «смена контакта»). | узаконить in-modal ввод как отдельный сценарий и убрать из FR5.2.1-3/-5 ссылку на 1.2/1.2.2 (оставить её только как «Не входит: backend») От бизнеса: хорошо, уточнили БРД. |
| #OQ5.2.1-3 | Код FR5.2.1-4, FR5.2.1-5 | Требование говорит: для почты различаются привязка и смена — заголовок «Укажите новый адрес…» (смена) vs «Укажите адрес…» (привязка); уведомление «обновлена» (смена) vs «подтверждена» (привязка). В коде заголовок один на оба случая («Укажите адрес электронной почты»), уведомление всегда «подтверждена». Признак emailVerified на вызывающей стороне есть, но для текстов не используется. \ check_contacts_texts.dart:8,10; edit_profile_screen.dart:435,456,466-467 | Бизнес (Герман) | Open | Признак уже доступен (emailVerified). (А, рекоменд.) реализовать два заголовка и два уведомления по BRD, ветвление по emailVerified; (Б) если различие не нужно — упростить FR5.2.1-4/-5 до одной формулировки. | Жду решения от бизнеса От бизнеса: доработать на два заголовка, вариант А, вес 2. |
| #OQ5.2.1-4 | Код вне BRD | Что нашли: в экране «Настройки» есть пункт «Изменить пароль аккаунта» (→ PassChangeRoute). В BRD 5.2.1 смена пароля не упоминается ни в Scope, ни в FR. \ profile_settings_screen.dart:262-267 | Бизнес (Герман) | Open | Границы раздела. (А, рекоменд.) оставить смену пароля в отдельном разделе настроек и явно указать это в Scope «Не входит» 5.2.1; (Б) включить смену пароля в «Редактирование учётных данных» и дописать FR. | оставить смену пароля в отдельном разделе настроек и явно указать это в Scope «Не входит» От бизнеса: ок, вариант А. |
| #OQ5.2.1-5 | Код FR5.2.1-6 | Требование говорит: при некорректном email — ошибка «Некорректный email» под полем + кнопка недоступна. В коде валидация есть (checkEmailPattern) и управляет показом кнопки, но текст ошибки под полем не выводится: поле errorMessage в NewContactEnter объявлено, но нигде не рендерится — пользователь не видит причину. \ new_contact_enter.dart:67,119-122,303; regex.dart:25-67 | Разработка | Закрывает PM | Валидация работает, не хватает вывода текста. Закрываю сам: выводить «Некорректный email» под полем при непустом невалидном значении (использовать существующий errorMessage) → тикет в Bitrix. Если продукту достаточно скрытой кнопки — тогда убрать требование текста из FR5.2.1-6 (правка BRD). | Жду решения от бизнеса От бизнеса: доработка, вес 2 — выводить «Некорректный email» под полем при непустом невалидном значении. |
| #OQ5.2.1-6 | Код FR5.2.1-2, FR5.2.1-4 | Требование говорит: кнопка «Продолжить» при пустом/невалидном вводе недоступна (показана в неактивном состоянии). В коде кнопка отрисовывается только if (isConfirmed) — при невалидном вводе она полностью скрыта, а не показана disabled. \ new_contact_enter.dart:303-394 | Разработка | Закрывает PM | Расхождение состояния кнопки, продуктового выбора почти нет. Закрываю сам: показывать «Продолжить» всегда, в disabled-состоянии при невалидном вводе (ближе к BRD) → тикет в Bitrix. Если продукт хочет скрытую кнопку — узаконить в FR5.2.1-2/-4. | узаконить скрытую кнопку в FR5.2.1-2/-4. От бизнеса: недоработка, вес 1. Отсутствие кнопки ведет к тупику клиента, поэтому она должна быть видна и указывать на то, что клиент ввел данные некорректно и должен повторить попытку. |
| #OQ5.2.1-7 | Код FR5.2.1-2 | Требование говорит: открывается экран «Смена номера телефона» с заголовком. В коде открывается нижний лист (buildScrollableModalBottomSheet, высота 0.8) с removeTitle: true и title: ';' — отдельного экрана и заголовка «Смена номера телефона» нет; «Укажите новый номер» — это текст тела листа. \ edit_profile_screen.dart:388-396; new_contact_enter.dart:184-190 | Бизнес (Герман) | Closed | (А, рекоменд.) согласовать формулировку BRD с фактом (нижний лист без шапки, заголовок в теле); (Б) если нужен именно экран с заголовком — доработать открытие (полноэкранный роут / шапка листа). | огласовать формулировку BRD с фактом (нижний лист без шапки, заголовок в теле) От бизнеса: уточнили БРД. |
| #OQ5.2.1-8 | Код FR5.2.1-3 | Проблема: после подтверждения показывается «Номер телефона успешно обновлен», в BRD — «Номер телефона обновлен». Мелкое расхождение текста. \ edit_profile_screen.dart:402-403 | Разработка | Закрывает PM | Косметика, продуктового выбора нет. Закрываю сам: привести к одному варианту («Номер телефона обновлён» по BRD либо зафиксировать «успешно обновлён» в BRD) → тикет в Bitrix. | зафиксировать «успешно обновлён» в BRD От бизнеса: формулировка длинная, «успешно» не вмещается в одну строку (проверили с Денисом), поэтому исправить: доработка, вес 2. |
Вопросы по сверке с кодом
BRD 5.2.1 v0.1 · booking.mobile.flutter · commit
1c4ad0e/ веткаorigin/main(2026-09-08) · дата сверки 2026-09-08 — повторная (дельта) сверка по итогам дейликов, вторая итерация; предыдущие сверки: 2026-07-10 commitdad0c65(полная), 2026-09-08 commit2b93d4fa(дельта №1) · якорьlib/src/feature/check_email_phone_modals/+lib/src/feature/profile_page/edit_profile/(вход в экран:profile_page/profile/widget/profile_title.dart) · маршрутизация без сверки с гайдбуком (не передан) Досверка №2, 2026-09-08 (commit1c4ad0e, mergedev→main): дельта2b93d4fa→1c4ad0e(коммитd8f0a99«additional information form server») правит ровно 4 из 8 открытых вопросов раздела: (1) OQ5.2.1-3 — заголовок листа и уведомление для email теперь различают привязку/смену через новый параметрisEmailChange(=emailVerifiedсо стороны вызова):CheckContactsTexts.NewContactTitle_Email({required isChange})→ «Укажите новый адрес…» vs «Укажите адрес…»,CheckContactsTexts.EmailUpdatedNotification({required isChange})→ «обновлена» vs «подтверждена» — check_contacts_texts.dart:12,18; check_email_phone_main.dart:21,31,79; new_contact_enter.dart:49-56,194; edit_profile_screen.dart:494,511-515. (2) OQ5.2.1-5 — текст «Некорректный email» теперь реально рендерится под полем (errorMessageвычисляется поcheckEmailPatternи выводитсяText, если поле не пустое и невалидно) — new_contact_enter.dart:69,119-124,305-317. (3) OQ5.2.1-6 — кнопка «Продолжить» больше не скрывается условиемif (isConfirmed), а всегда отрисована и переходит в disabled-вид (onTap: null, серые цвета) при невалидном вводе — new_contact_enter.dart:322-341. (4) OQ5.2.1-8 — уведомление после смены телефона убрало слово «успешно»: «Номер телефона обновлён» вместо «Номер телефона успешно обновлен», как и просил бизнес («не вмещается в одну строку») — edit_profile_screen.dart:436-439. Эти четыре пункта переведены в FR-таблице в «Реализовано»/сняты из ссылок (FR5.2.1-2, FR5.2.1-4, FR5.2.1-6 → «Реализовано»; FR5.2.1-3 и FR5.2.1-5 сохраняют «Частично», у них остаётся нерешённый OQ5.2.1-2 — ввод кода реализован in-modalConfirmedPinPage, а не через экраны 1.2/1.2.2, как всё ещё написано в Scope «Не входит»; этот кусок в дельте не менялся). OQ5.2.1-1, OQ5.2.1-4, OQ5.2.1-7 (точка входа, смена пароля, экран vs нижний лист) вне этой дельты — соответствующие файлы (profile_title.dart) не менялись. Сами строки открытых вопросов не редактирую — детали и таблица «было → стало» в5.2.1-mobile.changes.md. Дельта-сверка 2026-09-08: междуdad0c65и2b93d4faсценарии 5.2.1 функционально не менялись;edit_profile_screen.dart— толькоdart format. Вregex.dart:66-70(commitd757e9c«search params», помечен «BRD 1.2, bug 07») ужесточена валидация TLD email (было без верхней границы длины — принимало «domdomdomd»; стало 2–9 букв) — усиливаетcheckEmailPattern, но не закрывает OQ5.2.1-5: тот вопрос про то, что текст «Некорректный email» под полем не рендерится (errorMessageвNewContactEnterобъявлен, но нигде не выводится) — это по-прежнему так (new_contact_enter.dart:62,110-113,303актуально соответствует). Также без изменений: подпись «Изменить пароль аккаунта»→«Изменить пароль» (OQ5.2.1-4,profile_settings_screen.dart:167вместо старого:262-267— переехала и сократилась при переработке коммитамиdd54f5d/9db8346, но сам факт «смена пароля не входит в scope 5.2.1» не поменялся); кнопка «Продолжить» по-прежнему скрыта, а не disabled (OQ5.2.1-6); тост «Номер телефона успешно обновлен» (OQ5.2.1-8) без изменений. Все 6 FR и все 8 OQ перепроверены — новых расхождений и закрытых вопросов не найдено, статусы без изменений; детали —5.2.1-mobile.changes.md. Сводка (после досверки 1c4ad0e): вопросов 8 (бизнесовых 4 / программных 4, без изменений — новых OQ не заводили, только закрытия) · подтверждено без вопросов 3 (FR5.2.1-2, FR5.2.1-4, FR5.2.1-6) · отрезано находок обратного прохода 4 (сверка 2b93d4fa) + 0 (сверка 1c4ad0e) Под особым вниманием: FR5.2.1-3/FR5.2.1-5 остаются «Частично» — единственная оставшаяся причина: ввод кода реализован внутри той же модалки (ConfirmedPinPage), а не в разделах 1.2/1.2.2, как написано в Scope (OQ5.2.1-2, вопрос вне этой дельты); FR5.2.1-1 (вход в экран не из «Настройки профиля») вне этой дельты, статус без изменений.
Бизнесовые
| № | Связано с | Что в BRD | Что в коде | Где в коде |
|---|---|---|---|---|
| Б1 | FR5.2.1-1 | Пользователь открывает редактирование учётных данных из раздела Mobile 5.2 Настройки профиля | Вход в экран редактирования — из выпадающего меню в шапке профиля («Редактировать профиль»), а не из «Настроек». Экран «Настройки» (ProfileSettingsScreen) ссылки на редактирование учётных данных не содержит (там гео, смена пароля/код-пароля, удаление аккаунта). Клик по телефону/почте на самом экране редактирования сценарии открывает корректно — нужно решение, какой вход канонический | profile/widget/profile_title.dart:219,229-233; profile_settings/profile_settings_screen.dart:81-573 (нет пункта); клики: edit_profile/edit_profile_screen.dart:386-411, 444-474 |
| Б2 | FR5.2.1-3, FR5.2.1-5 | После отправки контакта интерфейс переводит пользователя к вводу кода в разделах Mobile 1.2 Регистрация / Mobile 1.2.2 Подтверждение почты (ввод кода вынесен в «Не входит») | Ввод кода реализован внутри той же модалки отдельной страницей ConfirmedPinPage (3-я страница PageView), с собственными текстами и вызовами approveCodeUpdatePhoneMobile / approveCodeUpdateEmailMobile. Переходов на экраны 1.2 / 1.2.2 нет — нужно решение, переиспользовать экраны регистрации или оставить отдельную реализацию | check_email_phone_main.dart:65-88; modals/confirmed_pin_page.dart:141-233; cubit/check_contacts_modal_cubit.dart:52-81; identity_repository.dart:13,17 |
| Б3 | FR5.2.1-4, FR5.2.1-5 | Для почты различаются привязка и смена: заголовок «Укажите новый адрес электронной почты» (смена) vs «Укажите адрес электронной почты» (привязка); уведомление «Электронная почта обновлена» (смена) vs «подтверждена» (привязка) | Заголовок один на оба случая — «Укажите адрес электронной почты»; уведомление всегда «Электронная почта подтверждена». Признак «привязка/смена» на вызывающей стороне есть (emailVerified), но для текстов не используется — нужно решение, различать ли формулировки | check/utils/check_contacts_texts.dart:8,10; edit_profile/edit_profile_screen.dart:435,456,466-467 |
| Б4 | вне BRD (обратный проход) | — | В экране «Настройки» есть пункт «Изменить пароль аккаунта» (→ PassChangeRoute). В BRD 5.2.1 «Редактирование учётных данных» смена пароля не упоминается ни в Scope, ни в FR — нужно решение, относится ли смена пароля к этому разделу или живёт отдельно | profile_settings/profile_settings_screen.dart:262-267 |
Рекомендация / варианты решения
- Точка входа (Б1) — расхождение в описанном пути. Вариант А (рекоменд.): привести BRD/дизайн к факту — вход через меню шапки профиля, зафиксировать это в FR5.2.1-1. Вариант Б: если по продукту вход должен быть из «Настроек» — завести задачу на добавление пункта в
ProfileSettingsScreenи скорректировать код. - Место ввода кода (Б2) — сейчас две независимые реализации ввода кода (регистрация 1.2/1.2.2 и модалка смены контакта). Вариант А (рекоменд.): узаконить in-modal ввод как отдельный сценарий и убрать из FR5.2.1-3/-5 ссылку на 1.2/1.2.2 (оставив её только как «Не входит: backend-логика»). Вариант Б: если нужна единая точка ввода кода — переиспользовать экраны 1.2/1.2.2 и удалить
ConfirmedPinPage(сокращает дублирование, но требует прокидывать контекст «смена контакта»). - Привязка vs смена почты (Б3) — признак уже доступен (
emailVerified). Вариант А (рекоменд.): реализовать два текста заголовка и два уведомления по BRD, ветвление поemailVerifiedна вызывающей стороне. Вариант Б: продукт решает, что различие не нужно — тогда упростить FR5.2.1-4/-5 до одной формулировки. - Смена пароля (Б4) — определить границы раздела. Вариант А (рекоменд.): оставить смену пароля в отдельном разделе настроек и явно указать это в Scope «Не входит» 5.2.1. Вариант Б: включить смену пароля в «Редактирование учётных данных» и дописать FR.
Программные
| № | Связано с | Что в BRD | Что в коде | Где в коде |
|---|---|---|---|---|
| П1 | FR5.2.1-6 | При некорректном email интерфейс показывает ошибку «Некорректный email» под полем и оставляет «Продолжить» недоступной | Валидация email есть (checkEmailPattern), но она только управляет показом кнопки; текст ошибки под полем не выводится — поле errorMessage в NewContactEnter объявлено, но нигде не рендерится. Пользователь не видит причину — нужно решение по показу текста ошибки | modals/new_contact_enter.dart:67,119-122,303; core/utils/regex.dart:25-67 |
| П2 | FR5.2.1-2, FR5.2.1-4 | Кнопка «Продолжить» при пустом/невалидном вводе недоступна (показана в неактивном состоянии) | Кнопка «Продолжить» отрисовывается только if (isConfirmed) — при невалидном вводе она полностью скрыта, а не показана disabled. Отличается от «недоступна» по BRD | modals/new_contact_enter.dart:303-394 |
| П3 | FR5.2.1-2 | Интерфейс открывает экран «Смена номера телефона» с заголовком | Открывается нижний лист (buildScrollableModalBottomSheet, высота 0.8) с removeTitle: true и title: ';' — отдельного экрана и заголовка «Смена номера телефона» нет; заголовок «Укажите новый номер» — это текст тела листа | edit_profile/edit_profile_screen.dart:388-396; check/modals/new_contact_enter.dart:184-190 |
| П4 | FR5.2.1-3 | После подтверждения — уведомление «Номер телефона обновлен» | Показывается «Номер телефона успешно обновлен» — расхождение в тексте уведомления | edit_profile/edit_profile_screen.dart:402-403 |
Рекомендация / варианты решения
- Текст ошибки email (П1) — Вариант А (рекоменд.): выводить «Некорректный email» под полем при непустом невалидном значении (использовать уже существующий
errorMessage/добавитьTextпод полем). Вариант Б: если по продукту достаточно скрытой кнопки — синхронизировать FR5.2.1-6 с фактом (убрать требование текста ошибки). - Кнопка «недоступна» vs скрыта (П2) — расхождение в состоянии кнопки. Вариант А (рекоменд.): показывать «Продолжить» всегда, в disabled-состоянии при невалидном вводе (ближе к BRD и привычнее пользователю). Вариант Б: узаконить текущее поведение (скрытая кнопка) в FR5.2.1-2/-4.
- Экран vs нижний лист и заголовок (П3) — Вариант А (рекоменд.): согласовать формулировку BRD с фактом (нижний лист без шапки, заголовок в теле). Вариант Б: если нужен именно экран с заголовком — доработать открытие (полноэкранный роут / шапка листа).
- Текст уведомления (П4) — Вариант А (рекоменд.): привести к одному варианту («Номер телефона обновлен» по BRD либо зафиксировать «успешно обновлен» в BRD). Мелкое, но влияет на согласованность формулировок.