Направление работ: Mobile Код раздела: 5.3 Раздел: Профиль > Настройки приложения Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 13.07.26
1. Назначение
Раздел описывает управление параметрами входа, геолокацией, уведомлениями и темой оформления мобильного приложения, а также удаление аккаунта.
2. Ключевые понятия
Настройки приложения — раздел мобильного приложения, в котором пользователь управляет местоположением, темой оформления, параметрами входа и уведомлениями.
Код-пароль и биометрия — способы быстрого входа в приложение по коду, Face ID или Touch ID.
3. Scope
Входит
S1: Настройки приложения и переходы в соседние разделы
S2: Удаление аккаунта
Не входит
- смена код-пароля — смена пароля, создание и изменение код-пароля, настройка биометрии
- Mobile 5.3.2 Привязанные карты и добавление новых — просмотр и добавление банковских карт
- Mobile 1.2 Регистрация — регистрация после удаления аккаунта
4. BR
- Back: 1.3 Аккаунты и пользователи > Клиенты
- Back: 1.3.1 Аккаунты и пользователи > Клиенты > Клиентская зона доступа
- Back: 1.3.2 Аккаунты и пользователи > Клиенты > Характеристики клиента
5. Функциональные требования (UC + FR)
FR – functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR5.3-1 | Пользователь открывает настройки приложения | Интерфейс открывает экран «Настройки» и показывает разделы «Местоположение», «Тема оформления», «Авторизация» и «Уведомления», действие «Удалить аккаунт» и версию приложения. | 1 | Частично — OQ5.3-2, OQ5.3-3 | |
| S1: FR5.3-2 | Пользователь управляет автоматическим определением местоположения | Интерфейс позволяет включить или отключить настройку «Определять автоматически» и показывает её текущее состояние. | 1 | Реализовано — OQ5.3-12 | |
| S1: FR5.3-3 | Пользователь включает автоматическое определение местоположения впервые | Интерфейс вызывает системный запрос разрешения приложению использовать геолокацию. После предоставления разрешения интерфейс включает настройку «Определять автоматически». | 1 | Частично — OQ5.3-4 | |
| S1: FR5.3-4 | Пользователь выбирает тему оформления | Интерфейс позволяет выбрать один из вариантов «Системная», «Темная» или «Светлая» и применяет выбранную тему к приложению. | 1 | Не реализовано — OQ5.3-5 | |
| S1: FR5.3-5 | Пользователь изменяет пароль или задает новый код-пароль | По нажатию «Изменить пароль» или «Задать новый код-пароль» интерфейс переводит пользователя в раздел смена код-пароля. | 1 | Реализовано — OQ5.3-13 | |
| S1: FR5.3-6 | Пользователь включает или отключает вход по код-паролю | Интерфейс позволяет управлять настройкой «Использовать код-пароль» и показывает её текущее состояние. | 1 | Не реализовано — OQ5.3-6 | |
| S1: FR5.3-7 | Пользователь управляет входом по Face ID или Touch ID | Если код-пароль включен, интерфейс позволяет включить или отключить «Вход по Face ID/Touch ID». Если код-пароль отключен, настройка биометрии недоступна. | 1 | Реализовано (в 5.3.1) — OQ5.3-7 | |
| S1: FR5.3-8 | Пользователь открывает настройку уведомлений | Интерфейс открывает список типов уведомлений: «О новых заказах», «Об оплатах», «Об отменах», «Смена статуса заявки» и «Мероприятия (рассылка Март)» и показывает выбранные типы. | 1 | Не реализовано — OQ5.3-8 | |
| S1: FR5.3-9 | Пользователь выбирает типы уведомлений | Интерфейс позволяет независимо включить или отключить каждый доступный тип уведомлений и сохраняет сделанный выбор. | 1 | Не реализовано — OQ5.3-8 | |
| S1: FR5.3-10 | Пользователь управляет уведомлениями по e-mail | Интерфейс позволяет включить или отключить настройку «Уведомление по e-mail» и показывает её текущее состояние. | 1 | Не реализовано — OQ5.3-9 | |
| S2: FR5.3-11 | Пользователь инициирует удаление аккаунта | По нажатию «Удалить аккаунт» интерфейс показывает подтверждение «Удалить аккаунт?» с предупреждением «Все ваши данные будут удалены» и действиями «Удалить» и «Отмена». | 1 | Реализовано — OQ5.3-14 | |
| S2: FR5.3-12 | Пользователь отменяет удаление аккаунта | По нажатию «Отмена» интерфейс закрывает подтверждение и оставляет пользователя на экране «Настройки» без удаления аккаунта. | 1 | Реализовано — OQ5.3-14 | |
| S2: FR5.3-13 | Пользователь подтверждает удаление аккаунта | По нажатию «Удалить» интерфейс удаляет аккаунт и показывает сообщение «Аккаунт удалён» с пояснением «Для восстановления, обратитесь в поддержку в течение 3 дней» и действием «Закрыть». | 1 | Частично — OQ5.3-10 | |
| S2: FR5.3-14 | Пользователь закрывает сообщение об удалении аккаунта | По нажатию «Закрыть» интерфейс переводит пользователя в раздел 1.2 Регистрация. | 1 | Не реализовано — OQ5.3-11 |
6. Открытые вопросы
Пин-контекст. BRD 5.3 v0.1 · репо
booking.mobile.flutter(Flutter/Dart) · commitdad0c65/ веткаdev· дата сверки 2026-07-14 · якорьlib/src/feature/profile_page/profile_settings/(экранprofile_settings_screen.dart), опорные слои:feature/settings/(гео/тема),feature/secure/(код-пароль/биометрия). Точка входа — Профиль → «Настройки». Сводка. 14 строк: Open разработке — 8 · Open бизнесу — 2 · Закрывает PM — 0 · Подтверждено — 3 · плюс перенесённый из BRD OQ5.3-1 (Open, Продукт/Back). Требования: Реализовано — 5, Частично — 3, Не реализовано — 6. Отрезано находок обратного прохода — 4. Маршрутизация без сверки с гайдбуком — гайдбук на вход не передавался; продуктовые/спорные вопросы отнесены бизнесу как «подтвердить нечем», технические дефекты — разработке.
| ID | Источник | Вопрос | Кому | Статус | Рекомендации |
|---|---|---|---|---|---|
| OQ5.3-1 | Внешний комментарий Figma | Сохраняются ли настроенные код-пароль и Face ID/Touch ID после отключения соответствующей настройки или при повторном включении требуется настройка заново? | Продукт / Back | Open | Из кода видно: отключение биометрии переводит тип защиты в pass и сохраняет хэш код-пароля — биометрию можно включить заново без переввода (secure_cubit.dart:167-171). А удаление код-пароля (deactivateSecure / «Удалить код-пароль») стирает хэш (secure_cubit.dart:174-180, pin_settings_screen.dart:156-159) — код-пароль и биометрию придётся настраивать заново. Подтвердить, что такое поведение — целевое. |
| OQ5.3-2 | Код FR5.3-1 | Требование говорит: экран «Настройки» показывает разделы «Местоположение», «Тема оформления», «Авторизация» и «Уведомления». В коде отрисованы только «Местоположение» и «Авторизация»; разделы «Тема оформления» и «Уведомления» закомментированы и на экране не появляются. \ profile_settings_screen.dart:202 (Местоположение), :246 (Авторизация); закомментированы: :229-245 (Тема), :325-362 (Уведомления) | Разработка (Владислав) | Open | (А, реком.): если разделы должны быть — раскомментировать и довести Тему (см. OQ5.3-5) и Уведомления (см. OQ5.3-8, OQ5.3-9); (Б): если они отложены — зафиксировать это в BRD, чтобы «Настройки» не заявляли неготовый функционал. |
| OQ5.3-3 | Код (сверх BRD, область FR5.3-1) | Проблема: на экране есть незадокументированный раздел «Отладка» с кнопкой «Тест Sentry», отправляющей тестовое исключение в Sentry, и «пасхалка» по 10 тапам на строку версии (открывает картинку с внешнего URL). BRD этих элементов не описывает. Должны ли они попадать в продовую сборку для клиентов? \ profile_settings_screen.dart:366-406 (Отладка/«Тест Sentry»), :535-568 (пасхалка на версии) | Бизнес (Герман) | Open | (А, реком.): скрыть отладочный раздел и пасхалку за debug-флагом / dev-сборкой, чтобы клиент их не видел; (Б): если оставляют осознанно — внести в BRD. Технически прячется тривиально. |
| OQ5.3-4 | Код FR5.3-3 | Требование говорит: при первом включении интерфейс вызывает системный запрос геолокации и включает настройку после предоставления разрешения. В коде системный запрос вызывается (Geolocator.requestPermission), но настройка «Определять автоматически» сохраняется как включённая безусловно — код не дожидается и не проверяет факт выдачи разрешения ОС; в ветке «первого запуска» значение форсится в true даже если пользователь пытается выключить. \ location_service.dart:34-39 (requestPermission), settings_bloc.dart:248-267 (первый запуск → setGeoAccess(true) без проверки результата), settings_scope.dart:214-217 (// TODO: implement setPermit) | Разработка (Владислав) | Open | (А, реком.): включать настройку только при фактически выданном разрешении (проверять результат requestPermission / checkPermission), иначе оставлять выключенной; (Б): если «оптимистичное» включение целевое — описать в BRD, что тумблер отражает намерение, а не статус разрешения ОС. |
| OQ5.3-5 | Код FR5.3-4 | Требование говорит: интерфейс позволяет выбрать тему «Системная»/«Тёмная»/«Светлая» и применяет её. В коде инфраструктура темы есть (SettingsBloc._updateTheme, setThemeMode), но UI выбора темы на экране закомментирован, а setThemeMode ниоткуда из UI не вызывается — сменить тему пользователь не может; приложение работает в теме по умолчанию (ThemeMode.system). \ profile_settings_screen.dart:229-245 (закомм. UI выбора), settings_scope.dart:171-175 (setThemeMode без вызовов из UI), app_theme.dart:326 (default mode: system) | Разработка (Владислав) | Open | (А, реком.): подключить закомментированный переключатель к SettingsScope...setThemeMode — бэкенд-логика уже готова, нужен только UI-провод; (Б): если выбор темы отложен — убрать раздел из BRD/экрана до реализации. |
| OQ5.3-6 | Код FR5.3-6 | Требование говорит: интерфейс позволяет управлять настройкой «Использовать код-пароль» и показывает её текущее состояние. В коде тумблер — заглушка: заголовок «Вариантно! Использовать/Задать код-пароль», isToggled захардкожен в false (состояние не отражается), а по переключению просто открывается экран код-пароля; реальные isUsePass/setUsePass закомментированы и в scope, и в блоке. \ profile_settings_screen.dart:305-319; закомм.: settings_scope.dart:220-228, settings_bloc.dart:110-113, :161-218 | Разработка (Владислав) | Open | (А, реком.): либо реализовать настоящий тумблер (раскомментировать updateUsePass, связать состояние), либо заменить его на пункт-навигацию и убрать вид тумблера, чтобы не вводить в заблуждение. Включение/отключение код-пароля сейчас фактически живёт в 5.3.1 («Удалить код-пароль» — pin_settings_screen.dart:156-159). |
| OQ5.3-7 | Код FR5.3-7 + Scope | Требование говорит: на экране настроек, при включённом код-пароле, можно управлять «Вход по Face ID/Touch ID», иначе настройка недоступна. В коде такой тумблер реализован и работает (показывается при поддержке биометрии и настроенном код-пароле, включает/выключает через activate/deactivateBiometric), но живёт в разделе 5.3.1 (экран код-пароля), а не на экране 5.3. При этом BRD одновременно относит биометрию к FR5.3-7 (раздел 5.3) и в Scope-«Не входит» к 5.3.1 — внутреннее противоречие. \ pin_settings_screen.dart:177-228 (тумблер, гейтинг biometricType != null), secure_cubit.dart:160-171 | Бизнес (Герман) / PM | Open | Решить, где живёт настройка биометрии: если это часть экрана 5.3 — перенести требование туда по факту не получится (реализовано в 5.3.1) → убрать FR5.3-7 из 5.3 и оставить в 5.3.1; либо оставить как есть и снять пометку Scope-«Не входит». Поведенчески требование выполнено. |
| OQ5.3-8 | Код FR5.3-8, FR5.3-9 | Требование говорит: интерфейс открывает список типов уведомлений («О новых заказах», «Об оплатах», «Об отменах», «Смена статуса заявки», «Мероприятия (рассылка Март)»), показывает выбранные и позволяет независимо включать/отключать каждый с сохранением. В коде раздела уведомлений нет: секция закомментирована, отдельного кода/моделей уведомлений в проекте не найдено; в закомментированном варианте были лишь тумблеры Push и e-mail без типов и без сохранения. \ profile_settings_screen.dart:325-362 (закомм.); поиск по типам уведомлений и notification-фичам — совпадений нет | Разработка (Владислав) | Open | (А): реализовать список типов и сохранение (нужен бэкенд-контракт настроек уведомлений — уточнить у Back); (Б, бизнесу): подтвердить точный набор из пяти типов и что значит «Мероприятия (рассылка Март)». Пока функционал отсутствует полностью. |
| OQ5.3-9 | Код FR5.3-10 | Требование говорит: интерфейс позволяет включить/отключить «Уведомление по e-mail» и показывает состояние. В коде тумблер закомментирован; в прежнем варианте он менял лишь локальный флаг через setState, без сохранения на бэкенд. \ profile_settings_screen.dart:351-359 (закомм.) | Разработка (Владислав) | Open | Реализовать вместе с блоком уведомлений (OQ5.3-8): тумблер с чтением/записью состояния на бэкенд. Сейчас настройка отсутствует. |
| OQ5.3-10 | Код FR5.3-13 | Требование говорит: по «Удалить» интерфейс удаляет аккаунт и показывает «Аккаунт удалён» с пояснением про восстановление в 3 дня и действием «Закрыть». В коде порядок инвертирован: по «Удалить» аккаунт не удаляется — сразу показывается диалог «Аккаунт удалён»; фактическое удаление (gRPC IdentityService.ArchiveAccount + выход из аккаунта) вызывается только по «Закрыть». Сообщение об успехе показывается до и независимо от результата запроса; ветка успеха в кубите недостижима (fold вложен в if (res is Left)), ошибка удаления нигде не выводится (на ProfileSettingsCubit нет BlocListener). Тексты диалога совпадают с BRD дословно. \ profile_settings_screen.dart:427-430 («Удалить» → maybePop(1)), :452-519 (диалог), :497-498 («Закрыть» → deleteAccount), profile_settings_cubit.dart:16-33 (мёртвая ветка успеха), delete_profile_repository.dart:33-49 | Разработка (Владислав) | Open | (реком.): вызывать deleteAccount по «Удалить», показывать «Аккаунт удалён» только по фактическому успеху, а ошибку — обрабатывать (сейчас проглатывается); починить if (res is Left)/fold, чтобы success-ветка отрабатывала. Это дефект логики, не продуктовый выбор. |
| OQ5.3-11 | Код FR5.3-14 | Требование говорит: по «Закрыть» интерфейс переводит пользователя в раздел «1.2 Регистрация». В коде перехода в регистрацию нет: «Закрыть» вызывает deleteAccount → AuthEventSignOut (выход), после чего гард роутера при разлогине ведёт на экран входа (LoginRoute), а не на регистрацию. \ profile_settings_screen.dart:491-499, delete_profile_repository.dart:46 (AuthEventSignOut), гард: см. app_router.dart (!isAuthorized → LoginRoute) | Разработка (Владислав) | Open | (реком.): после удаления вести на «1.2 Регистрация», как задано в BRD (после удаления вход в несуществующий аккаунт бессмыслен). (Бизнесу): подтвердить целевой экран после удаления — регистрация или вход. |
| OQ5.3-12 | Код FR5.3-2 | Что подтверждено: тумблер «Определять автоматически» реализован, отражает состояние (isGeoPermit) и переключает его через SettingsScope.setGeoPermit → SettingsBloc.updateGeoPermit с сохранением в хранилище гео. \ profile_settings_screen.dart:215-227, settings_bloc.dart:222-302 | — | Подтверждено | Расхождения по управлению тумблером нет. Нюанс с запросом разрешения ОС при первом включении — см. OQ5.3-4. |
| OQ5.3-13 | Код FR5.3-5 | Что подтверждено: переходы в 5.3.1 работают: «Изменить пароль аккаунта» → PassChangeRoute, пункт код-пароля («Установить/Изменить код-пароль») → PinSettingsRoute. \ profile_settings_screen.dart:262-267, :293-302 | — | Подтверждено | Расхождения нет (точка перехода, детально 5.3.1 не сверялась). Тексты пунктов в коде отличаются от BRD («Изменить пароль аккаунта», «Установить/Изменить код-пароль») — при желании выровнять формулировки. |
| OQ5.3-14 | Код FR5.3-11, FR5.3-12 | Что подтверждено: диалог подтверждения удаления реализован дословно — заголовок «Удалить аккаунт?», текст «Все ваши данные будут удалены», действия «Удалить» и «Отмена»; «Отмена» закрывает диалог и оставляет пользователя на «Настройках» без удаления. \ profile_settings_screen.dart:414-446 (диалог), :439-442 («Отмена» → Navigator.pop) | — | Подтверждено | Расхождения нет. Дефекты дальнейшего потока удаления (после «Удалить»/«Закрыть») — см. OQ5.3-10, OQ5.3-11. |