BRD Widget 4.1 Отображение без входа в аккаунт
Направление работ: Widget Код раздела: 4.1 Раздел: Блок данных потенциального заказа > Отображение без входа в аккаунт Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 11.08.26
1. Назначение
Раздел описывает отображение блока данных потенциального заказа в виджете для пользователя без входа в аккаунт и развилку идентификации при переходе к оформлению.
Пользователь может открыть виджет и собирать бронирование, не авторизуясь: выбирать площадку, дату и время и видеть итоговую стоимость. При переходе к оформлению интерфейс показывает окно авторизации: пользователь либо входит в аккаунт, либо пропускает вход и оформляет заказ через упрощенную регистрацию, вводя контактные данные на шаге оформления.
Для пользователя без входа стоимость рассчитывается без клиентского контекста.
Документ описывает только гостевое отображение потенциального заказа, его стоимость и развилку идентификации. Содержимое окна входа — раздел 3.1; ввод контактных данных при пропуске входа — раздел 3.2.1; данные вошедшего клиента — раздел 6.1; позиции, скидки, оплата, правила — раздел 5; расчет на бэкенде — Back 4.
Раздел зависит от Back: 4.2 Стоимость заказа и позиций и Back: 3.1 Состав заказа.
2. Ключевые понятия
Блок данных потенциального заказа — сводка формируемого бронирования: площадка и зал, вид работ, количество человек, дата, время — и его итоговая стоимость.
Потенциальный заказ — еще не созданный заказ, который пользователь собирает в виджете перед подтверждением.
Расчет стоимости — вычисление итоговой цены по выбранным параметрам заказа.
Пользователь без входа — посетитель виджета без авторизованного аккаунта, который может просматривать площадки и стоимость и собирать бронирование.
Развилка идентификации — окно авторизации, которое интерфейс показывает при переходе к оформлению: пользователь либо входит в аккаунт, либо пропускает вход и продолжает по упрощенной регистрации.
Пропуск входа — продолжение оформления без авторизации: пользователь вводит контактные данные (имя, телефон, email) на шаге оформления, а регистрация выполняется незаметно для пользователя (упрощенная регистрация).
Формат работы виджета — настройка партнерской зоны widgetFormat, определяющая доступность пропуска входа: WithRegistration (0) — оформление только после входа; WithoutRegistration (1) — доступен пропуск входа с упрощенной регистрацией.
Как контактные данные попадают в заказ. Заказ не хранит контакты клиента отдельно — для создания заказа достаточно идентификатора клиента (
ClientId). Смысл развилки идентификации в том, чтобы этот идентификатор получить: либо входом в аккаунт, либо упрощенной регистрацией, которая создает карточку клиента по имени, телефону и email и возвращает ее идентификатор. Контактные данные живут в карточке клиента — см. Back: 1.3 Клиенты.
3. Scope
Входит
S1: Гостевое отображение параметров потенциального заказа
S2: Отображение и пересчет итоговой стоимости без клиентского контекста
S3: Развилка идентификации при переходе к оформлению — вход или пропуск
Не входит
- Widget: 4.2 Блок данных потенциального заказа > Отображение после входа в аккаунт
- Widget: 3.1 Авторизация > Вход (содержимое окна авторизации)
- Widget: 3.2.1 Упрощенная регистрация в виджете (ввод контактных данных при пропуске входа)
- Widget: 5.1 Дополнительные позиции к заказу
- Widget: 5.2 Скидки, комментарий и правила
- Widget: 6.1 Профиль > Информация о клиенте
- Back: 4.2 backend-логика расчета стоимости
- Back: 3.1 backend-логика состава заказа
4. BR
Указаны в пункте 4 разделов Back: 4.2 Стоимость заказа и позиций и Back: 3.1 Состав заказа.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: #FR4.1-1 | Пользователь без входа открывает виджет | Интерфейс позволяет без авторизации просматривать площадки, календарь и стоимость и собирать параметры потенциального заказа — вид работ и/или количество человек, дата, время. | 1 | Реализовано по коду — требуется подтверждение QA | |
| S1: #FR4.1-2 | Пользователь видит итоговую стоимость | Интерфейс показывает блок Итого с итоговой ценой, при наличии скидки — старую цену рядом, и индикатор загрузки на время пересчета. | 1 | Реализовано по коду — требуется подтверждение QA | |
| S2: #FR4.1-3 | Стоимость рассчитывается для гостя | Интерфейс рассчитывает стоимость без идентификатора клиента: применяются базовые цены и общие акции, но не применяются М-баллы и персональные клиентские условия. | 1 | Реализовано по коду — требуется подтверждение QA | |
| S2: #FR4.1-4 | Пользователь меняет параметры заказа | Интерфейс автоматически пересчитывает итоговую стоимость при изменении даты, времени, опций или состава позиций и не допускает показ устаревшего результата при частых изменениях. | 2 | Реализовано по коду — требуется подтверждение QA | |
| S3: #FR4.1-5 | Пользователь переходит к оформлению | При действии перехода к оформлению (Далее) интерфейс показывает окно авторизации до перехода на шаг оформления. | 1 | Не реализовано — Далее сразу открывает оформление, см. OQ4.1-1 | |
| S3: #FR4.1-6 | Пользователь входит из окна авторизации | Интерфейс позволяет войти в аккаунт из окна авторизации и продолжить оформление как вошедший клиент; содержимое окна входа описано в 3.1. | 1 | Не реализовано — окна авторизации нет, см. OQ4.1-1 | |
| S3: #FR4.1-7 | Пользователь пропускает вход | Если партнер включил формат работы без регистрации (widgetFormat = WithoutRegistration), интерфейс позволяет пропустить вход и перейти на шаг оформления, где обязателен ввод имени, телефона и email; по этим данным незаметно для пользователя создается карточка клиента, и полученный идентификатор клиента используется при создании заказа (упрощенная регистрация 3.2.1). | 1 | Не реализовано — нет ни кнопки пропуска, ни формы контактов, см. OQ4.1-1 | |
| S3: #FR4.1-8 | Заказ создается по итогам развилки | Интерфейс создает заказ только с непустым идентификатором клиента, полученным при входе или упрощенной регистрации. Запрет действует на двух уровнях: интерфейс не даёт подтвердить бронирование без идентификатора клиента, и контракт создания заказа отклоняет запрос с пустым ClientId. | 1 | Не реализовано — заказ создается с пустым ClientId, см. OQ4.1-3 |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус |
|---|---|---|---|---|
| #OQ4.1-1 | Код | Требование говорит: при переходе к оформлению интерфейс показывает окно авторизации, из которого клиент либо входит, либо пропускает вход и продолжает по упрощенной регистрации (FR4.1-5/6/7). В коде развилки нет вообще: Далее просто переключает шаг (goToCheckout() устанавливает step = 'checkout'), проверки авторизации в сценарии бронирования нет ни одной, кнопки Пропустить и полей На чьё имя будет заказ / Номер телефона / Email не существует. Требуется реализация развилки целиком — вместе с разделом Widget: 3.2.1, который без нее недостижим. \ widgets/booking/composables/useLayout.ts:261-263, widgets/booking/ui/OrderBaseForm.vue:325-338 | Разработка | Закрыт |
| #OQ4.1-2 | Код | Что уточнено: настройка формата работы виджета существует — widgetFormat в партнерской зоне со значениями WithRegistration (0) и WithoutRegistration (1). В коде она доезжает до виджета и разбирается конфигурацией, но её никто не читает: потребителей вне слоя shared/api/widget-config нет, на поведение виджета она не влияет. При реализации развилки подключить widgetFormat как условие доступности пропуска входа. \ shared/api/widget-config/api/widgetConfig.api.ts:18,96 | Разработка | Закрыт |
| #OQ4.1-3 | Код | Что уточнено: для создания заказа от клиента достаточно идентификатора клиента — контакты в заказе не хранятся. В коде заказ создается с ClientId: clientId.value, который может быть пустым, то есть бронь оформляется вообще без привязки к клиенту и партнер не может связаться с заказчиком. Подтвердить, что создание заказа с пустым ClientId должно быть запрещено, и на каком уровне ставить проверку — в виджете, в контракте создания заказа или в обоих. Решение: создание заказа с пустым ClientId запрещено, проверка ставится на обоих уровнях — в виджете (кнопка бронирования недоступна) и в контракте создания заказа (запрос отклоняется). Серверная проверка нужна, чтобы запрет нельзя было обойти прямым вызовом API, как это происходит с белым списком доменов (Widget: 8.2, OQ8.2-1). Требование зафиксировано в FR4.1-8. \ widgets/order-form/model/useOrderFormStore.ts:255-294 | Разработка | Закрыт |