Направление работ: WebLk Код раздела: 3.3 Раздел: Профиль партнёра > Основные настройки Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 08.07.26
1. Назначение
Данный раздел описывает экран основных настроек профиля партнерской зоны в кабинете партнера.
Партнер видит основную информацию о компании, платежную информацию, доступные вкладки настроек и может настроить профиль компании. Платежная информация отображается в разделе как часть настроек, но заполняется аккаунт-менеджером.
Раздел зависит от Back: 1.4 Партнеры и Back: 2.8 Настройки партнерской зоны. Ограничения по правам доступа используются только как состояние интерфейса.
2. Ключевые понятия
Основные настройки - раздел WebLk 3.3, в котором партнер просматривает и настраивает публичную информацию профиля компании в текущей партнерской зоне.
Партнерская зона - обособленная сущность партнера в системе, к которой относятся объекты, площадки, услуги, сотрудники, платежные и операционные настройки.
Настройки партнерской зоны - набор параметров, которые определяют формат взаимодействия партнера с платформой, сотрудниками и клиентами.
Платежная информация - отображаемый блок с параметрами онлайн-платежей и инструкциями оплаты; заполнение и изменение этих данных выполняет аккаунт-менеджер.
3. Scope
Входит
S1: Просмотр раздела «Основные настройки» и переходы в соседние подразделы S2: Настройка профиля компании S3: Состояния интерфейса
Не входит
- WebLk 3.1 Главный экран - главный экран профиля партнера и пустое состояние, из которого партнер переходит к настройке профиля компании
- WebLk 3.3.1 Уведомления - настройка уведомлений профиля партнера
- WebLk 3.3.2 Данные организации - данные организации и юридическая информация
- WebLk 3.4 Настройки правил работы - настройки правил работы с заказами, сборами, заявками и абонементами
- WebLk 3.6 Сотрудники и доступ - управление сотрудниками, ролями и правами доступа
- Backend/API-контракты, структура БД и техническая реализация
4. BR
Указаны в пункте 4 разделов Back: 1.4 Партнеры и 2.8 Настройки партнерской зоны. Ограничения интерфейса по правам пользователя используются точечно по правилам Back: 1.2 Организация доступа к системе.
5. Функциональные требования (UC + FR)
FR - functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Cценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: #FR3.3-1 | Партнер открывает раздел «Основные настройки» | Интерфейс открывает раздел «Основные настройки» в контексте текущей партнерской зоны и показывает блок основной информации, блок платежной информации и вкладки: «Основная информация», «Уведомления», «Организация», «Платежная информация», «Сборы», «Правила отмены», «Заявки» и «Абонементы» (на будущую реализацию). | 1 | Реализовано OQ3.3-1, OQ3.3-5 | |
| S1: #FR3.3-2 | Партнер просматривает основную информацию компании | Интерфейс показывает логотип, публичное название компании, основной телефон, email, тип кабинета, описание, владельца и его контактные данные: телефон и email, а также иконки социальных сетей. Иконки заполненных социальных сетей залиты цветом, незаполненных - серым. | 1 | Частично OQ3.3-2, OQ3.3-3, OQ3.3-4, OQ3.3-20 | |
| S1: #FR3.3-4 | Партнер переходит в соседние подразделы настроек | Интерфейс позволяет перейти из вкладок, расположенных рядом с вкладкой «Основная информация», в 3.3.1 Уведомления и 3.3.2 Данные организации. | 1 | Реализовано OQ3.3-5 | |
| S2: #FR3.3-5 | Партнер переходит к первичной настройке профиля компании | Если партнер еще не заполнял информацию о компании, интерфейс показывает пустое состояние из раздела 3.1 Главный экран и позволяет перейти к настройке профиля компании в текущем разделе. | 1 | Частично OQ3.3-6, OQ3.3-7 | |
| S2: #FR3.3-6 | Партнер открывает настройку профиля компании | Интерфейс открывает форму «О компании» и показывает поле для добавления логотипа, выбор типа кабинета, поле публичного названия, выпадающий список городов, описания деятельности, контактных данных, выбор предпочтительного способа связи и поля публичных страниц. | 1 | Частично OQ3.3-8, OQ3.3-10 | |
| S2: #FR3.3-7 | Партнер добавляет или меняет логотип компании | Интерфейс позволяет добавить или заменить логотип компании и показывает требования к загружаемому изображению. | 1 | Реализовано OQ3.3-4 | |
| S2: #FR3.3-8 | Партнер редактирует описание компании | Интерфейс позволяет выбрать тип кабинета, указать публичное название, город и описание деятельности компании. | 1 | Частично OQ3.3-8, OQ3.3-9 | |
| S2: #FR3.3-9 | Партнер редактирует контакты и публичные страницы | Интерфейс позволяет указать телефон, email, предпочтительный способ связи, Telegram, ВКонтакте и сайт компании. | 1 | Частично OQ3.3-10 | |
| S2: #FR3.3-10 | Партнер выбирает предпочтительный способ связи | Интерфейс раскрывает список способов связи и позволяет выбрать один или несколько доступных каналов для контакта с компанией. | 3 | Не реализовано OQ3.3-10 | |
| S2: #FR3.3-11 | Партнер сохраняет изменения профиля компании | Интерфейс сохраняет введенные данные профиля компании. Если изменена контактная почта, интерфейс запускает подтверждение почты и после подтверждения позволяет продолжить настройку уведомлений в разделе 3.3.1 Уведомления. | 1 | Частично OQ3.3-11, OQ3.3-12 | |
| S3: #FR3.3-12 | Партнер открывает раздел без полных прав доступа | Интерфейс показывает доступные для просмотра данные, блокирует недоступные поля и скрывает или отключает действие сохранения, если у пользователя нет прав редактировать настройки. Подробности прав доступа раскрываются в разделе 3.6 Сотрудники и доступ. | 2 | Не реализовано OQ3.3-13 | |
| S3: #FR3.3-13 | Партнер открывает раздел во время загрузки данных | Интерфейс показывает состояние загрузки раздела «Основные настройки» с плейсхолдерами основной информации и платежной информации до получения данных. | 2 | Реализовано OQ3.3-19 | |
| S3: #FR3.3-14 | Партнер открывает раздел на разных устройствах | Интерфейс адаптирует страницу основных настроек, карточку основной информации, блок платежной информации, формы редактирования и состояния интерфейса для desktop, laptop и tablet и mobile. | 2 | Частично OQ3.3-14 |
6. Открытые вопросы
Сверка с кодом: BRD 3.3 v0.1 · репозиторий
musbooking_personal_account· commit93383777/main· 31.07.26 · якорьpages/partner-profile/settings/partner-zone.vueСводка: 20 вопросов (Open 18 · Подтверждено 2) Маршрутизация без сверки с гайдбуком (гайдбук не передавался).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| #OQ3.3-1 | Код FR3.3-1 | Требование говорит: раздел называется «Основные настройки», а среди вкладок есть «Платежная информация». В коде заголовок страницы — «Настройки кабинета», в хлебных крошках тот же экран назван «Настройки партнерской зоны», а вкладка с платежами называется «Параметры платежей». Получается три разных названия одного экрана и ещё одно расхождение по названию вкладки. Партнёру и поддержке трудно понять, что это один и тот же раздел. Нужно зафиксировать одно название экрана и одно название вкладки. \ pages/partner-profile/settings/partner-zone.vue:7 (заголовок «Настройки кабинета») \ pages/partner-profile/settings/partner-zone.vue:62 (крошка «Настройки партнерской зоны») \ plugins/settingsRegistry.client.ts:41 (вкладка «Параметры платежей») | Бизнес | Решён | (А) привести код к терминам BRD — «Основные настройки» и «Платежная информация» (рекоменд.). (Б) зафиксировать в BRD названия из кода. После выбора синхронизировать макеты и тексты подсказок. | Закрепить название «Основные настройки» из BRD. Один экран сейчас носит три имени — заголовок «Настройки кабинета», хлебная крошка «Настройки партнерской зоны» и название раздела в BRD. Привести код к BRD: и заголовок страницы, и крошка — «Основные настройки»; вкладку «Параметры платежей» переименовать в «Платежная информация». Тикет в Bitrix (правка текстов). |
| #OQ3.3-2 | Код FR3.3-2 | Проблема: в карточке основной информации поле «Основной телефон» заполняется телефоном владельца кабинета, а не контактным телефоном компании. Тот же номер чуть ниже показывается второй раз в блоке владельца, поэтому партнёр всегда видит два одинаковых телефона. В данных партнёрской зоны есть отдельное поле контактного телефона компании, но оно не используется нигде в интерфейсе. Требование FR3.3-2 разделяет основной телефон компании и телефон владельца. \ components/Settings/Tab/BasicInfoTab.vue:57-58 (основной телефон берётся из телефона владельца) \ components/Settings/Tab/BasicInfoTab.vue:99 (тот же телефон владельца в блоке владельца) \ entities.fsd/partner-zone/types/partnerZone.types.ts:155-161 (неиспользуемое поле контактного телефона) | Разработка | Решён | Завести тикет в Bitrix: выводить в поле «Основной телефон» контактный телефон компании, телефон владельца оставить только в блоке владельца, при пустом значении показывать прочерк. | Подключить контактный телефон компании. Поле «Основной телефон» брать из PartnerZoneContactInfo.phoneNumber (оно есть в модели и не используется нигде) и редактировать по клику именно его. Телефон владельца оставить только в блоке владельца. Сейчас оба поля берут owner?.phone, поэтому партнёр видит один номер дважды, а редактируя «основной телефон компании» — меняет личный телефон владельца. Тикет в Bitrix. |
| #OQ3.3-3 | Код FR3.3-2 | Что нашли: кроме перечисленных в требовании данных карточка показывает отдельный блок «Менеджер» с аватаром и ФИО аккаунт-менеджера. В BRD этот блок не описан ни в составе основной информации, ни в ключевых понятиях. Блок виден всегда, в том числе когда менеджер не назначен — тогда выводится пустое имя и картинка-заглушка вместо аватара. Нужно решить, остаётся ли блок в разделе и что показывать, если менеджера нет. \ components/Settings/Tab/BasicInfoTab.vue:109-120 (блок «Менеджер») \ components/Settings/Tab/BasicInfoTab.vue:201-203 (заглушка аватара менеджера) | Бизнес | Решён | (А) добавить блок «Менеджер» в FR3.3-2 и описать поведение без назначенного менеджера (рекоменд.). (Б) убрать блок из раздела. Правки в коде делать после ответа. | Блок «Менеджер» остаётся, но получает пустое состояние с переходом. Внести блок в FR3.3-2 как часть карточки основной информации. Когда аккаунт-менеджер не назначен, вместо пустого имени и картинки-заглушки показывать явное пустое состояние со стрелкой-переходом в раздел 3.6 Сотрудники и доступ — чтобы блок не выглядел сломанным и вёл партнёра туда, где состав сотрудников настраивается. Тикет в Bitrix. |
| #OQ3.3-4 | Код FR3.3-2, FR3.3-7 | Проблема: карточка ищет логотип среди файлов партнёрской зоны по признаку «тип файла 0 и приоритет 0», а загрузчик отправляет файл на сервер вообще без указания типа и приоритета и помечает его у себя типом 1. В справочнике типов 0 — это иконка, а 1 — изображение, то есть чтение и запись ориентируются на разные значения. Из-за этого после загрузки логотипа карточка может продолжать показывать картинку-заглушку. Нужно проверить на стенде, отображается ли только что загруженный логотип, и согласовать единый признак основного логотипа. \ components/Settings/Tab/BasicInfoTab.vue:166-177 (поиск логотипа по типу 0 и приоритету 0) \ components/UI/ImageManager.vue:555-565 (загрузка без типа и приоритета) \ classes/api/ResourcesService.ts:22-27 (иконка равна 0, изображение равно 1) | Разработка | Решён | Завести тикет в Bitrix: передавать при загрузке логотипа явные тип и приоритет и использовать тот же признак при чтении в карточке; добавить проверку «загрузил логотип — увидел его в карточке». | Согласовать единый признак основного логотипа. Сейчас чтение ищет файл по fileType === 0 && priority === 0 (в справочнике 0 = Ico), а загрузчик отправляет файл без типа и приоритета, помечая у себя типом 1 (Img) — чтение и запись смотрят на разные значения, из-за чего только что загруженный логотип может не появиться. Зафиксировать один признак основного логотипа, привести к нему и чтение, и запись, и поправить комментарий в коде — он утверждает «FileType = 0 - изображение», что противоречит справочнику и, судя по всему, и породило путаницу. Перед правкой воспроизвести на стенде: возможно, тип проставляет бэкенд. Тикет в Bitrix. |
| #OQ3.3-5 | Код FR3.3-1, FR3.3-4 | Проблема: из раздела условий оплаты есть переход в настройки сразу на вкладку платежей по ссылке с якорем, и такая же ссылка объявлена в общем справочнике маршрутов. Страница настроек этот якорь нигде не читает — активная вкладка вычисляется только по текущему шагу формы. В результате переход открывает раздел на первой вкладке, а не на платежах, и пользователь попадает не туда, куда вела кнопка. Нужно либо поддержать якорь, либо убрать его из ссылок. \ components/PaymentMethods/PaymentTermsTab.vue:724 (переход на адрес с якорем) \ shared.fsd/config/routes/pageRoutes.ts:49 (маршрут с якорем) \ pages/partner-profile/settings/partner-zone.vue:107-115 (активная вкладка считается только по шагу) | Разработка | Решён | Завести тикет в Bitrix: при открытии раздела учитывать якорь и открывать соответствующую вкладку; список поддерживаемых прямых ссылок закрепить в BRD. | Поддержать якорь, причём для всех вкладок. Страница настроек должна читать якорь из адреса и открывать соответствующую вкладку — сделать механизм универсальным, чтобы адрес любой вкладки можно было передать ссылкой, а не только #payment. Сейчас якорь объявлен в маршруте partnerZonePayment и используется кнопкой из условий оплаты, но страница его не читает вовсе, и переход всегда открывает первую вкладку. Тикет в Bitrix. |
| #OQ3.3-6 | Код FR3.3-5 | Требование говорит: пустое состояние первичной настройки показывается, если партнёр ещё не заполнял информацию о компании. В коде признак первичной настройки считается сразу по семи блокам данных — реквизиты компании, банковские счета, фактический и юридический адреса, учредитель, контакты и описание — и включается, если пустыми оказались хотя бы пять блоков из семи. В расчёт попадают юридические и банковские данные, которые к профилю компании отношения не имеют. Партнёр, заполнивший профиль компании, но не заполнивший реквизиты, увидит режим первичной настройки, а карточка основной информации будет скрыта целиком. Нужно согласовать, по каким данным считается «профиль не заполнен». \ stores/partnerSettings.ts:503-551 (расчёт признака по порогу в 70 процентов пустых блоков) \ components/Settings/Tab/BasicInfoTab.vue:14 (при этом признаке профиль компании скрывается) | Бизнес | Решён | (А) считать первичной настройкой только незаполненный профиль компании — публичное название, тип кабинета, контакты, описание (рекоменд.). (Б) оставить текущий расчёт и описать его в BRD. После ответа завести тикет на правку. | Отказаться от бинарного режима в пользу индикатора заполненности. Решение заказчика: доработать макет — при заполнении профиля показывать процентный индикатор и полосу заполнения, а не переключать экран в режим «первичной настройки» целиком. Это снимает исходную проблему: сейчас признак считается эвристикой emptySections >= Math.ceil(7 * 0.7) по семи блокам, включая реквизиты и банковские счета, поэтому партнёр с заполненным профилем, но без реквизитов, видит режим первичной настройки, а карточка основной информации скрывается целиком. С прогресс-индикатором прятать карточку не нужно вовсе — партнёр видит и данные, и то, сколько осталось заполнить. Требуется макет от дизайна (состав блоков в подсчёте процента) + доработка. Тикет в Bitrix. |
| #OQ3.3-7 | Код FR3.3-5 | Проблема: мастер первичной настройки открывается автоматически только при переходе по адресу со специальным признаком. Такой адрес объявлен в справочнике маршрутов, но ни один экран его не использует, а карточка профиля на главном экране ведёт в настройки по обычному адресу без признака. В итоге автоматический запуск мастера не срабатывает никогда, и партнёру приходится дополнительно нажимать кнопку настройки уже внутри раздела. Требование FR3.3-5 предполагает переход к настройке профиля прямо из пустого состояния главного экрана. \ pages/partner-profile/settings/partner-zone.vue:191-202 (автозапуск только по признаку в адресе) \ shared.fsd/config/routes/pageRoutes.ts:48 (объявленный, но нигде не используемый маршрут) \ components/dashboard/Settings.vue:127-129 (переход без признака) | Разработка | Решён | Завести тикет в Bitrix: вести переход из пустого состояния главного экрана по маршруту с признаком запуска мастера и покрыть сценарий проверкой. | Вести на настройки с признаком wizard. Карточка профиля на главном экране должна использовать уже объявленный маршрут partnerZoneWizard (?wizard=1) вместо обычного адреса — тогда мастер первичной настройки откроется сразу, как требует FR3.3-5, и партнёру не придётся нажимать кнопку второй раз внутри раздела. Маршрут в справочнике есть, но им никто не пользуется. Учесть связь с OQ3.3-6: если режим первичной настройки заменяется индикатором заполненности, запуск мастера остаётся явным действием партнёра, а не следствием состояния данных. Тикет в Bitrix. |
| #OQ3.3-8 | Код FR3.3-6, FR3.3-8 | Требование говорит: в форме «О компании» партнёр выбирает город из выпадающего списка городов. В коде вместо списка стоит поле с подсказками по адресу и подписью «Город по умолчанию», куда можно ввести и улицу с домом — подсказки приходят из внешнего адресного сервиса. Это и другой способ ввода, и другой смысл поля: вместо выбора из справочника получается свободная адресная строка. Нужно решить, что требуется — закрытый список городов или адрес с подсказками. \ components/Settings/Steps/BaseInfoStep.vue:50-57 (поле подсказок по адресу с подписью «Город по умолчанию») | Бизнес | Решён | (А) заменить поле на выбор города из справочника, как описано в BRD (рекоменд.). (Б) зафиксировать в BRD адресную строку с подсказками. Выбор влияет на состав сохраняемых данных партнёрской зоны. | Разделить на два поля: город из справочника и адрес отдельно. Сейчас это одно поле с подсказками из внешнего адресного сервиса и подписью «Город по умолчанию», куда можно ввести и улицу с домом — смешаны две разные сущности. Завести отдельный выбор города из справочника (город становится ссылкой на справочник, по нему можно фильтровать и агрегировать) и отдельное адресное поле с подсказками. Закрывает и вопрос сохранения города — см. OQ3.3-9. Тикет в Bitrix (фронт + проверка, что бэкенд принимает город отдельным полем). |
| #OQ3.3-9 | Код FR3.3-8 | Проблема: город, введённый в форме «О компании», не сохраняется и не подставляется обратно. Форма записывает значение в поле, которого нет в модели данных профиля, а при отправке на сервер город берётся из другого поля, заполняемого только из ответа сервера. При открытии раздела поле города всегда выглядит пустым, а после сохранения введённое значение теряется. Требование FR3.3-8 в части города фактически не работает. \ components/Settings/Steps/BaseInfoStep.vue:271-274 (форма пишет в поле address) \ stores/partnerSettings.ts:27-40 (в модели профиля есть city, поля address нет) \ stores/partnerSettings.ts:803-820 (при сохранении город берётся из city) | Разработка | Решён | Завести тикет в Bitrix: связать поле города формы с полем модели, подставлять сохранённое значение при открытии и проверить, что после сохранения город возвращается с сервера. | Чинить одной задачей вместе с OQ3.3-8. Отдельно править привязку к city смысла нет — поле всё равно переделывается: по OQ3.3-8 город выносится в отдельный выбор из справочника, а адрес — в отдельное поле с подсказками. В той же задаче завести оба поля в модель PartnerData (сейчас форма пишет в partnerData.address, которого в интерфейсе нет вовсе) и в набор, уходящий на сервер. Проверить приёмку обоих полей на бэкенде. Тикет в Bitrix — общий с OQ3.3-8. |
| #OQ3.3-10 | Код FR3.3-6, FR3.3-9, FR3.3-10 | Требование говорит: партнёр выбирает предпочтительный способ связи, список раскрывается, и можно отметить один или несколько каналов. В коде такого поля нет нигде — ни в форме «О компании», ни в модели данных профиля, ни в наборе полей, который уходит на сервер при сохранении. Поиск по всему проекту по смыслу «предпочтительный способ связи» не находит ни одной реализации. Требование FR3.3-10 не реализовано целиком, а FR3.3-6 и FR3.3-9 из-за этого выполнены не полностью. \ components/Settings/Steps/BaseInfoStep.vue:70-135 (в форме только телефон, email и публичные страницы) \ stores/partnerSettings.ts:27-40 (в модели профиля поля способа связи нет) | Разработка | Решён | Завести тикет в Bitrix: добавить в форму выбор предпочтительных каналов связи с множественным выбором и сохранением на сервер; состав каналов согласовать с автором BRD до начала работ. | Понизить вес до 3 и отложить. Предпочтительный способ связи не реализован нигде — ни в форме, ни в модели, ни в отправке на сервер, — но приоритета не имеет. Вес FR3.3-10 меняется с 2 на 3, требование остаётся в BRD как целевое со статусом «Не реализовано»; упоминания в FR3.3-6 и FR3.3-9 сохраняются. Тикет заводить без срока — вернуться, когда появится сценарий, где этот признак реально используется. |
| #OQ3.3-11 | Код FR3.3-11 | Требование говорит: если изменена контактная почта, интерфейс запускает подтверждение почты и после подтверждения позволяет продолжить настройку уведомлений. В коде сохранение профиля просто отправляет данные на сервер и закрывает панель редактирования. Нет ни сравнения новой почты со старой, ни экрана подтверждения, ни перехода в раздел уведомлений. Поиск по разделу настроек не находит ни одного упоминания подтверждения почты. Сценарий FR3.3-11 выполнен только в части сохранения. \ components/Settings/Drawer/Settings.vue:228-246 (сохранение и закрытие без проверки почты) \ components/Settings/Steps/BaseInfoStep.vue:375-382 (сохранение шага «О компании» без подтверждения) | Разработка | Решён | Завести тикет в Bitrix: после сохранения сравнивать контактную почту с прежней, при изменении запускать подтверждение и после успеха предлагать переход в раздел уведомлений. | Реализовать подтверждение почты. При сохранении сравнивать новую контактную почту со старой и, если она изменилась, запускать подтверждение, а после него давать перейти к настройке уведомлений — как требует FR3.3-11. Сейчас сохранение просто отправляет данные и закрывает панель: ни сравнения, ни экрана подтверждения, ни перехода в уведомления нет. Тикет в Bitrix; при постановке уточнить, шлёт ли бэкенд код подтверждения на контактную почту компании или только на почту входа. |
| #OQ3.3-12 | Код FR3.3-11 | Проблема: если сохранение профиля завершилось ошибкой, партнёр об этом не узнаёт. Ошибка перехватывается и пишется только в техническую консоль браузера, сообщения на экране нет, форма остаётся открытой без каких-либо пояснений. Так же тихо теряется ошибка загрузки логотипа. Пользователь считает, что данные сохранены, хотя они не сохранились. \ components/Settings/Drawer/Settings.vue:200-202 (ошибка сохранения уходит только в консоль) \ components/Settings/Steps/BaseInfoStep.vue:329-331 (ошибка загрузки логотипа уходит только в консоль) | Разработка | Закрыт | Завести тикет в Bitrix: показывать пользователю сообщение об ошибке сохранения и не закрывать форму до успешного ответа сервера; тексты ошибок согласовать и внести в BRD. | Использовать существующий общий механизм, новый не заводить. Уточнение заказчика: в кабинете уже есть сквозной механизм показа ошибок — бэкенд всегда возвращает кастомный код, и чтобы сообщение появилось у партнёра, его достаточно пробросить через админку. Значит задача сводится к тому, чтобы путь сохранения профиля не глотал ответ: заменить console.error на обработку кода через общий механизм (то же для onLogoUploadError). Отдельной разработки механизма не требуется, тексты настраиваются в админке. Это же уточнение снимает оговорку, записанную ранее в OQ4.4-8 по ценам: там тоже нужно подключиться к общему механизму, а не изобретать показ ошибок заново. |
| #OQ3.3-13 | Код FR3.3-12 | Требование говорит: при неполных правах интерфейс показывает доступные данные, блокирует недоступные поля и скрывает или отключает сохранение. В коде раздел вообще не смотрит на права текущего пользователя: единственная проверка при входе — что пользователь авторизован, а хранилище прав используется только в редакторе ролей сотрудников, чтобы расставлять галочки в чужой роли. Все поля, кнопки редактирования и кнопка сохранения доступны любому, кто открыл раздел. Требование FR3.3-12 не реализовано. \ middleware/auth.global.ts:4-21 (проверяется только авторизация) \ stores/permissions.ts:15-21 (права хранятся только для редактора ролей) \ pages/partner-profile/settings/partner-zone.vue:1-36 (в разметке раздела нет ни одной проверки прав) | Разработка | Open | Завести тикет в Bitrix: получать права текущего пользователя на настройки партнёрской зоны и по ним переводить раздел в режим просмотра; перечень полей, доступных только на чтение, до начала работ согласовать с BRD 3.6. | В ту же общую задачу по правам, что и OQ4.5-1. Раздел не смотрит на права вообще: единственная проверка — факт авторизации, stores/permissions.ts обслуживает только редактор ролей сотрудников. Точечно чинить в «Основных настройках» не нужно — требуется сквозной механизм прав на весь кабинет партнёра (источник ролей, рантайм-проверка, правила блокировки полей и скрытия сохранения), после которого FR3.3-12 и FR4.5-4/-5 закрываются вместе. Вопрос остаётся Open до решения по общему механизму. |
| #OQ3.3-14 | Код FR3.3-14 | Проблема: адаптивность раздела сделана частично и тремя разными наборами контрольных точек. У страницы переключение колонок задано на 1024 и 768 пикселях, у карточки основной информации — на 1199, 1023 и 467, а общий справочник проекта использует 600, 960 и 1280. В блоке платежной информации и в форме «О компании» адаптивных правил нет ни одного. Отдельно: панель кнопок «Отмена» и «Сохранить» внутри боковой панели растянута на всю ширину экрана, а не по ширине самой панели. Требование FR3.3-14 про desktop, laptop, tablet и mobile выполнено не полностью. \ pages/partner-profile/settings/partner-zone.vue:310-352 (точки 1024) \ components/Settings/Tab/BasicInfoTab.vue:360-371 (точки 1199, 1023, 467) \ composables/useBreakpoint.ts:14-21 (справочник 600, 960, 1280) \ components/Settings/Drawer/Settings.vue:303-314 (панель кнопок на всю ширину экрана) | Разработка | Решён | Завести тикет в Bitrix: свести раздел к единому набору контрольных точек, добавить адаптив блоку платежной информации и форме редактирования, прижать панель кнопок к границам боковой панели; к тикету приложить макеты для tablet и mobile. | Привести раздел к единым контрольным точкам. Сейчас в разделе три разных набора: страница — 1024 и 768, карточка основной информации — 1199, 1023 и 467, общий справочник проекта — 600, 960 и 1280. Перевести раздел на общий справочник, добавить адаптивные правила блоку платежной информации и форме «О компании» (там их нет ни одного) и починить панель кнопок «Отмена»/«Сохранить», растянутую на всю ширину экрана вместо ширины боковой панели — это дефект вёрстки, а не решение. Тикет в Bitrix. |
| #OQ3.3-15 | Код (обратный проход) | Что нашли: в назначении раздела сказано, что платежная информация только отображается, а заполняет её аккаунт-менеджер. В интерфейсе же партнёр с кабинетом для юридических лиц может сам добавить параметр онлайн-платежа, отредактировать его, заархивировать и восстановить, а также добавить, отредактировать и заархивировать инструкцию оплаты. Для кабинета физических лиц вместо этого показана заглушка с просьбой обратиться к менеджеру. Нужно решить, кто на самом деле управляет этими данными и какие кнопки должен видеть партнёр. \ components/Settings/Tab/PaymentTab.vue:30-35 (кнопка добавления параметра платежа) \ components/Settings/Tab/PaymentTab.vue:96 (архивирование параметра платежа) \ components/Settings/Tab/PaymentTab.vue:151-159 (добавление инструкции оплаты) | Бизнес | Решён | (А) оставить партнёру только просмотр, а управление вынести в инструменты аккаунт-менеджера (рекоменд.). (Б) описать в BRD права партнёра на редактирование платежных параметров и инструкций. После ответа завести тикет. | Только отображение — BRD прав. Платежная информация заполняется аккаунт-менеджером, партнёр её лишь просматривает. Убрать из интерфейса самостоятельное управление: кнопки добавления параметра онлайн-платежа, редактирования, архивации и восстановления, а также управление инструкцией оплаты — сейчас всё это доступно партнёру с кабинетом для юрлиц. Заглушку для физлиц привести к общему виду (см. OQ3.3-16), различие по типу кабинета после правки становится ненужным. Тикет в Bitrix. |
| #OQ3.3-16 | Код (обратный проход) | Проблема: в интерфейсе платежной информации остались служебные тексты периода разработки. Всплывающая подсказка у кнопки добавления платежа прямо сообщает, что кнопка сделана для тестирования и её нужно будет убрать, а в заглушке для физических лиц выводится внутренняя формулировка о том, что у физлица и самозанятого не должно быть возможности настроить платежи самостоятельно. Эти тексты видит партнёр. Кроме того, в справочнике вкладок у «Сборов» и «Заявок» остались пометки о временно подставленных компонентах. \ components/Settings/Tab/PaymentTab.vue:33 (тестовый текст подсказки) \ components/Settings/Tab/PaymentTab.vue:16-19 (внутренняя формулировка в заглушке) \ plugins/settingsRegistry.client.ts:50 (пометка о временном компоненте) | Разработка | Решён | Завести тикет в Bitrix: убрать тестовую кнопку и заменить служебные тексты на согласованные формулировки; итоговые тексты заглушек взять из BRD. | Вычистить служебные тексты срочно. Их видит партнёр: подсказка у кнопки добавления платежа прямо сообщает, что кнопка сделана для тестирования и её нужно будет убрать, а заглушка для физлиц выводит внутреннюю формулировку про физлицо и самозанятого. Заменить на нормальные пользовательские формулировки, пометки о временно подставленных компонентах у вкладок «Сборы» и «Заявки» тоже убрать. Часть работы снимается решением по OQ3.3-15: тестовая кнопка удаляется вместе с самостоятельным управлением платежами. Тикет в Bitrix, приоритетный — дефект виден клиенту. |
| #OQ3.3-17 | Код (обратный проход) | Что нашли: карточка «Профиль компании» существует в двух почти одинаковых реализациях. Одна лежит в разделе основных настроек и берёт данные из хранилища настроек, вторая — в блоке настроек главного экрана и запрашивает те же данные напрямую. Копии уже разошлись: на главном экране подпись поля написана с опечаткой «Основой телефон», в разделе настроек она правильная. Дополнительно раздел построен на боковой панели, помеченной в коде как устаревшая, хотя в проекте уже есть её замена. Прежде чем сверять раздел дальше, нужно зафиксировать, какая из карточек эталонная. \ components/Settings/Tab/BasicInfoTab.vue:12-120 (карточка в разделе настроек) \ components/dashboard/Settings.vue:1-58 (та же карточка на главном экране, опечатка в строке 19) \ components/UI/layout/SimpleDrawer.vue:102 (пометка «устаревший» с указанием замены) | Разработка | Решён | Завести тикет в Bitrix: оставить одну реализацию карточки профиля компании и переиспользовать её на обоих экранах, попутно исправив опечатку «Основой телефон»; отдельным шагом перевести раздел на актуальную боковую панель. | Объединить в один компонент. Оставить одну реализацию карточки «Профиль компании» и переиспользовать её на главном экране — копии уже разошлись (на главном экране опечатка «Основой телефон», в разделе настроек подпись правильная), и без объединения они будут расходиться дальше. Заодно перевести раздел с боковой панели, помеченной в коде как устаревшая, на её действующую замену. Отмечу: это третий случай дублирования, найденный за сверку, — ранее обнаружены две реализации календаря (OQ5.2-12) и два компонента DataTable, причём во втором дублирование уже привело к регрессии. Тикет в Bitrix. |
| #OQ3.3-18 | Код (обратный проход) | Что нашли: в таблице функциональных требований раздела пропущен номер FR3.3-3 — нумерация идёт с FR3.3-1 и FR3.3-2 сразу на FR3.3-4. При этом в коде есть поведение, не привязанное ни к одному требованию: каждое поле карточки основной информации кликабельно и открывает форму редактирования сразу с фокусом на этом поле. Возможно, пропущенное требование как раз описывало этот сценарий и было удалено из таблицы. Нужно либо восстановить требование, либо подтвердить, что пропуск номера намеренный. \ components/Settings/Tab/BasicInfoTab.vue:56-82 (каждое поле карточки открывает редактор) \ components/Settings/Tab/BasicInfoTab.vue:235-238 (открытие формы с фокусом на конкретном поле) | Бизнес | Решён | (А) восстановить FR3.3-3 и описать в нём переход в редактирование по клику на поле карточки (рекоменд.). (Б) оставить пропуск и отметить его примечанием к таблице, чтобы он не читался как потерянное требование. | Восстановить FR3.3-3. Завести требование под пропущенным номером и описать в нём реально работающий сценарий: каждое поле карточки основной информации кликабельно и открывает форму редактирования сразу с фокусом на выбранном поле. Перенумеровывать таблицу не нужно — это сломало бы ссылки из открытых вопросов и смежных разделов. Отмечу: такой же пропуск найден в Back 3.2, где отсутствует BR3.2-10, — стоит проверить нумерацию и в остальных разделах. |
| #OQ3.3-19 | Код FR3.3-13 | Что подтверждено: пока данные раздела не загрузились, вместо содержимого показываются заглушки-плейсхолдеры — отдельная для карточки основной информации и отдельная для блока платежной информации. Дополнительно до окончания загрузки соседние вкладки заблокированы, и партнёр не может переключиться на них раньше времени. Требование FR3.3-13 выполнено. \ components/Settings/Tab/Wrappers/BasicInfoTabWrapper.vue:1-4 (плейсхолдер основной информации) \ components/Settings/Tab/Wrappers/PaymentTabWrapper.vue:1-4 (плейсхолдер платежной информации) \ pages/partner-profile/settings/partner-zone.vue:126-140 (блокировка вкладок на время загрузки) | — | Подтверждено | Отдельных действий не требуется. При будущих правках раздела сохранить оба плейсхолдера и блокировку вкладок как эталонное поведение. | — |
| #OQ3.3-20 | Код FR3.3-2 | Что подтверждено: иконки публичных страниц компании действительно меняют вид в зависимости от заполненности. Для ВКонтакте, Telegram и сайта подставляются разные файлы иконок — цветная, если ссылка заполнена, и приглушённая, если нет. При наведении показывается сама ссылка, а по клику открывается форма редактирования нужного поля. Эта часть требования FR3.3-2 выполнена. \ components/Settings/Tab/BasicInfoTab.vue:206-232 (выбор цветной или неактивной иконки) \ components/Settings/Tab/BasicInfoTab.vue:30-51 (подсказка со ссылкой и переход в редактирование) | — | Подтверждено | Отдельных действий не требуется. При сверке макетов учесть, что «серое» состояние сделано отдельным файлом иконки, а не прозрачностью цветной. | — |