Направление работ: Back Код раздела: 2.2 Объекты и предложения > Площадки партнеров Статус: Готов Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 23.06.26
1. Назначение
Раздел описывает площадку партнера как конечное предложение платформы, на которое клиент может оформить заказ.
Система хранит параметры площадки, связывает ее с объектом партнера и применяет к ней настройки, которые нужны для бронирования и отображения в интерфейсах.
Подробная логика объекта, цен, скидок, заказов, файлов, статистики и фронтовых сценариев раскрывается в соседних разделах.
2. Ключевые понятия
Площадка партнера — помещение, привязанное к объекту партнера, на которое пользователь может оформить заказ.
Объект партнера — сущность, к которой привязана площадка и от которой площадка может наследовать часть настроек. Подробнее описан в Back: 2.1.
Райдер площадки — описание характеристик и оборудования площадки.
Связанные площадки — площадки одной партнерской зоны, для которых может использоваться общее расписание. Подробнее описаны в Back: 2.2.1.
Правила работы с заказами — условия создания, оплаты, отмены и применения баллов, которые используются при заказе площадки и раскрываются в соседних разделах.
3. Scope
Входит
S1 Площадка партнера: конечное предложение платформы, помещение для заказа с обязательной привязкой к объекту партнера.
S2 Параметры и данные площадки: основные данные, характеристики помещения, вместимость, схема, райдер, параметры фильтрации, фото, видео и дополнительные материалы.
S3 Связанные настройки и данные площадки: доступность в интерфейсах, синхронизация, связанные площадки, режим и формат работы, наследуемые правила и транслируемые данные.
S4 Операции над площадками: архивация и восстановление площадок.
Не входит
-
Back: 2.1 Объекты партнеров
-
Back: 2.2.1 Площадки, связанные одним расписанием
-
Back: 2.4 Правила работы с заказами
-
Back: 2.5, 2.6, 2.7, 2.7.3 Позиции, цены, скидки и баллы
-
Back: 3.4, 4.5, 8.3.2, 9.6.1, 9.1, 9.2, 9.4.1 Отзывы, размещение, справочники, файлы, показатели и история
-
WebLk: 3.4, 4.2, 4.2.1 Настройки правил работы, управление площадками и модерация данных площадки
-
Mobile: 2.4, 2.4.1 Информация о площадке/услуге и выбор таймслотов
-
Widget: 1.3, 1.3.1, 2.1, 2.1.1, 2.1.2 Отображение по площадке и блок данных выбранной площадки
-
Catalog: 1.2, 2.2 Отображение по площадкам и выбор времени
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR2.2-1 | Система должна хранить площадку партнера как сущность, привязанную к объекту партнера | Площадка является помещением, на которое пользователь может оформить заказ. Подробнее объект партнера описан в Back: 2.1. | Системное | 1 | Реализовано — OQ2.2-30 |
| S1: BR2.2-2 | Площадка должна наследовать настройки объекта партнера с возможностью уточнения на уровне площадки в пределах настроек объекта | Изменения настроек на уровне площадки применяются только к этой площадке. | Бизнес | 1 | Частично — OQ2.2-2 |
| S2: BR2.2-3 | Карточка площадки должна хранить основные данные площадки | Состав данных: * объект, к которому привязана площадка * название * цвет площадки * описание | Системное | 1 | Частично — OQ2.2-9 |
| S2: BR2.2-4 | Карточка площадки должна хранить характеристики помещения | Состав данных: * площадь * габариты: длина, ширина, высота потолков * схема площадки * вместимость площадки * параметры фильтрации. Логика типов параметров фильтрации раскрывается в Back: 8.2.4. Логика хранения файлов раскрывается в Back: 9.6.1. | Системное | 1 | Реализовано |
| S2: BR2.2-5 | Если для площадки заполнены длина и ширина, система должна проверять соответствие площади габаритам | Проверка выполняется по формуле: длина × ширина = площадь. Допускается округление площади до целого числа. | Системное | 2 | Не реализовано — OQ2.2-20 |
| S2: BR2.2-6 | Карточка площадки должна хранить райдер площадки | Райдер хранится как текстовое описание характеристик площадки с HTML-форматированием. | Системное | 1 | Реализовано — OQ2.2-31, OQ2.2-19 |
| S2: BR2.2-7 | Система должна поддерживать райдер площадки в формате списка оборудования (после релиза реализация) | Состав данных: * категория позиции * наименование и модель позиции * габариты позиции * фотография позиции * инструкция. Модель хранения райдера требует подтверждения: через дополнительные позиции или отдельный справочник. | Системное | 3 | Не реализовано — OQ2.2-28, OQ2.2-19 |
| S2: BR2.2-8 | Карточка площадки должна хранить фото, видео и дополнительные материалы площадки | Состав данных: * фотографии площадки (минимум 3) * видео-обзор площадки * дополнительные видео, фото, аудио и PDF-материалы. Логика загрузки и хранения файлов раскрывается в Back: 9.6.1. | Системное | 1 | Реализовано |
| S3: BR2.2-9 | Для площадки должен задаваться список интерфейсов, в которых она доступна для бронирования | Связанные параметры доступности: активный тариф размещения и размер кэшбека по тарифу. Подробная логика размещения раскрывается в Back: 8.3.2 и Back: 4.5. | Бизнес | 2 | Частично — OQ2.2-6, OQ2.2-7 |
| S3: BR2.2-10 | Площадка должна поддерживать связь с интеграциями и другими площадками | Для интеграций хранятся идентификаторы синхронизаций, подключенных к площадке. Логика связанных площадок с общим расписанием раскрывается в Back: 2.2.1. | Системное | 1 | Реализовано |
| S3: BR2.2-11 | Для площадки должен задаваться режим работы | По умолчанию площадка наследует время работы объекта. Режим задается списком дней недели с диапазонами рабочих часов. | Бизнес | 1 | Частично — OQ2.2-4, OQ2.2-5, OQ2.2-15 |
| S3: BR2.2-12 | Для площадки должен задаваться формат работы | Допустимые значения: * онлайн-бронирование (значение по умолчанию) * по заявке | Бизнес | 1 | Частично — OQ2.2-3, OQ2.2-16 |
| S3: BR2.2-13 | Система должна поддерживать настройку отдельных режимов и форматов работы площадки по условиям (после релиза реализация) | Условия включают: * периоды действия * опции * диапазоны опций * дни недели * время действия | Системное | 3 | Не реализовано — OQ2.2-29 |
| S3: BR2.2-14 | Если для площадки не заданы отдельные правила работы с заказами, должны применяться правила объекта партнера | Правило относится к условиям создания, оплаты, отмены и правилам баллов. Подробная логика раскрывается в Back: 2.4 и Back: 2.7.3. | Бизнес | 1 | Частично — OQ2.2-17, OQ2.2-8 |
| S3: BR2.2-15 | По площадке должны транслироваться привязанные позиции, цены и скидки | Транслируются: * справочник привязанных позиций * список привязанных цен * список привязанных скидок с возможностью редактирования. Подробная логика раскрывается в Back: 2.5, Back: 2.6 и Back: 2.7. | Системное | 1 | Реализовано |
| S3: BR2.2-16 | По площадке должны транслироваться показатели площадки | Состав показателей: * количество пользователей, у которых площадка находится в избранном * средний рейтинг площадки * количество отзывов * количество заказов по источникам * диапазон стоимости площадки. Логика сбора данных и статистики раскрывается в Back: 9.1, Back: 9.4.1. | Системное | 2 | Частично — OQ2.2-21 |
| S3: BR2.2-17 | По площадке должны транслироваться последние записи истории изменений площадки | Логика истории операций с сущностями раскрывается в Back: 9.2. | Системное | 2 | Не реализовано — OQ2.2-22 |
| S4: BR2.2-18 | Система должна поддерживать архивацию и восстановление площадки | Архивация заменяет удаление площадки. Для площадки хранятся признак нахождения в архиве и дата архивации. Операции архивирования и восстановления выполняются при наличии отдельного права и формируют отдельный сигнал для других сервисов. Ограничения на архивацию площадки с активными заказами не применяются. | Системное | 1 | Реализовано — OQ2.2-23 |
Подстраницы
Открытые вопросы
BRD 2.2 v0.1 · booking-monorepo · commit
83423b21/main· 2026-07-15 · якорьsrc/services/booking.partner-managementСводка: вопросов 30 (Open 23 · Закрывает PM 5 · Подтверждено 2) · отрезано находок обратного прохода 8 Маршрутизация без сверки с гайдбуком (гайдбук на вход не передавался — позиция гайдбука нигде не додумывалась). Отрезано (перечислено, чтобы не читалось как «всё покрыто»): связь площадки с объектом не подкреплена ограничением целостности в базе; строгая связь «одна площадка — одна строка показателей» не обеспечена в базе; несимметричная обработка дублей при создании и изменении; недостижимая ветка наследования часов при опущенном поле; колонкаsource_idв таблице параметров фильтрации названа не по смыслу; ключ кэша правил не учитывает партнёрскую зону; недокументированный отбор правил «только изменявшиеся» (относится к Back: 2.4); две параллельные реализации очистки правил при смене часов (одна из них без завершения транзакции).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ2.2-2 | Код BR2.2-2 | Требование говорит: площадка наследует настройки объекта партнёра, но их можно уточнить на уровне площадки, и уточнение действует только на эту площадку. В коде наследование работает выборочно и в одну сторону: часы работы и процент баллов при создании берутся у объекта, если не заданы, и потом их можно уточнить; а формат работы уточнить нельзя вообще — он принудительно переписывается значением объекта при каждом сохранении площадки. Вдобавок при изменении часов объекта часы площадки пересчитываются под объект, то есть ранее сделанное уточнение затирается. — нужно решение: какие настройки площадка вправе уточнять и вправе ли объект перезаписывать уточнения. CreateRoomCommandHandler.cs:71-75, :89, :90; UpdateRoomCommandHandler.cs:123; RoomAggregate.cs:303-309 | Бизнес (Герман) | Open | (А) привести код к BRD: сделать формат собственным полем площадки, наследование — только начальным значением, синхронизацию часов — не затирающей уточнения (рекоменд., если площадка задумана самостоятельной сущностью). (Б) привести BRD к коду: записать, что формат живёт только на объекте, а часы объекта всегда главнее. Корневой вопрос — разблокирует OQ2.2-3 и OQ2.2-4. | докрутить формат работы, вариант А от бизнеса. UPD (Ксюша): не совсем логично получается, что площадка может работать вне расписания самого объект (дольше например, чем сам объект). Базово все зависит от требованийю Сейчас просто соблюдается иерархичность (объет по полномочиям выше площадки) |
| OQ2.2-3 | Код BR2.2-12 | Требование говорит: для площадки должен задаваться формат работы — онлайн-бронирование (по умолчанию) или по заявке. В коде сам перечень значений совпадает (онлайн-бронирование, по заявке), но задать формат на площадке нельзя: в запросах на создание и изменение площадки такого параметра нет вовсе, формат всегда берётся у объекта партнёра. Значения «онлайн по умолчанию» для площадки тоже нет — площадка получает то, что стоит у объекта. — нужно решение: формат — собственная настройка площадки или свойство объекта. CreateRoomCommand.cs:15-35 и UpdateRoomCommand.cs:14-39 (параметра формата нет); CreateRoomCommandHandler.cs:90; UpdateRoomCommandHandler.cs:123 | Бизнес (Герман) | Open | (А) добавить формат в запросы создания/изменения площадки и дефолт «онлайн» (рекоменд., BRD трактует формат как настройку площадки). (Б) убрать формат из BR2.2-12 и описать его в разделе объекта партнёра. Связать с OQ2.2-2 — решается тем же продуктовым выбором. | Недоработка, добавить формат в запросы создания/изменения площадки и дефолт «онлайн» UPD (Ксюша): дефолтное значение для площадки берётся из объекта, т.к. изначально предполагается, что она также будет работать (опять же отрабатывает иерархичность сущностей). Задавать площадки отдельное дефолтное значение будто не совсем логично. Надо уточнить у бизнеса, что в итоге нужно |
| OQ2.2-4 | Код BR2.2-11 | Требование говорит: по умолчанию площадка работает круглосуточно, без перерывов и выходных. В коде такого умолчания нет ни в каком виде: если часы при создании не переданы, площадка берёт часы объекта партнёра; если у объекта часов нет — площадка остаётся вообще без часов работы. Более того, при изменении площадки можно передать пустой список часов и обнулить режим работы — проверки при этом не срабатывают. — нужно решение: какое умолчание верное — круглосуточно (как в BRD) или часы объекта. CreateRoomCommandHandler.cs:71-75; RoomAggregate.cs:169; RoomAggregate.cs:498-503 (пустой список проходит без проверок) | Бизнес (Герман) | Open | (А) привести код к BRD: при создании без часов ставить круглосуточный режим, наследование объекта сделать явной опцией (рекоменд., если площадка должна быть доступна сразу). (Б) привести BRD к коду: записать, что по умолчанию площадка наследует часы объекта, а без часов объекта — не работает. Связать с OQ2.2-2. | Про круглосуточную работу Продакты связали требования с Бэк по Объектам, привели S3: BR2.2-11 к коду этот момент |
| OQ2.2-5 | Код BR2.2-11 | Требование говорит: режим задаётся списком дней недели с диапазонами рабочих часов — и всё. В коде правила заметно строже, чем в BRD, и нигде в требованиях не зафиксированы: дни можно указывать только наборами «все 5 будних», «оба выходных» или «все 7»; все будние дни обязаны иметь одинаковые часы, все выходные — тоже одинаковые между собой; интервалы внутри дня не могут не только пересекаться, но и просто соприкасаться (10:00–12:00 и 12:00–14:00 будут отклонены — нужен перерыв). — нужно подтверждение: это намеренные правила бизнеса или код строже требований. RoomAggregate.cs:505-509, :511-527, :529-547, :549-567, :569-581 | Бизнес (Герман) | Open | (А) дописать эти правила в BR2.2-11 (рекоменд. — код их уже соблюдает, и они выглядят осмысленно для расписания). (Б) ослабить код, если реальные площадки работают по другим графикам (например, разные часы по дням) — тогда правила мешают. | ДОРАБОТКА ПОСЛЕ РЕЛИЗА: привести код к БРД, добавить поддержку отдельных дней недели |
| OQ2.2-6 | Код BR2.2-9 | Требование говорит: для площадки должен задаваться список интерфейсов, в которых она доступна для бронирования. В коде список хранится, но задать или изменить его через методы API нельзя: такого параметра нет ни в создании, ни в изменении площадки. При создании выдаётся фиксированный набор (сайт, админка, мобильное приложение, виджет, портал, каталог), а меняется он только двумя путями — внутренней командой снятия с публикации и автоматически при подключении/отключении интеграций. Возможность задать список в доменной модели есть, но она не используется. — нужно решение: должен ли партнёр управлять списком интерфейсов вручную. CreateRoomCommand.cs:15-35, UpdateRoomCommand.cs:14-39 (параметра нет); RoomAggregate.cs:48-56, :93; RoomAggregate.cs:189, :215-218 (неиспользуемая ветка) | Бизнес/Разработка (Герман → Владислав) | Open | (А) добавить управление списком интерфейсов в изменение площадки (рекоменд., BRD прямо говорит «должен задаваться»). (Б) если набор намеренно фиксированный и управляется только размещением/интеграциями — переписать BR2.2-9 в терминах «список формируется системой», чтобы требование не обещало ручного управления. | UPD(Ксения): интерфейсы, которые отображаются в списке у площадки, влияют на её отображения в продуктах. Публикация (отображения в том же Mobile) непосредственно зависит от тарифов партнера, логики которых пока нет. Этот момент нужно уточнить у бизнеса |
| OQ2.2-7 | Код BR2.2-9 | Требование говорит: со списком интерфейсов связаны активный тариф размещения и размер кэшбека по тарифу. В коде из тарифа размещения по площадке берётся только процент кэшбека — ни стоимость размещения, ни скидка, ни лимиты не транслируются. Если активного размещения по интерфейсу нет, кэшбек по умолчанию равен 1 — и непонятно, это 1% или 100%; та же единица служит признаком «обычной, неприоритетной площадки» при сортировке, поэтому реальный кэшбек 1% неотличим от «размещения нет». — нужно подтверждение: какой кэшбек должен применяться без активного тарифа и в каких единицах. RoomReadOnlyRepository.cs:413, :1672 (значение по умолчанию 1m); :459, :462 (сортировка «больше 1 — приоритетная»); :374 (из тарифа выбирается только кэшбек) | Разработка | Open | (А) сделать умолчание 0% при отсутствии активного размещения и отделить признак приоритета от значения кэшбека (рекоменд. — безопаснее для расчёта баллов и снимает двусмысленность). (Б) оставить 1, но явно зафиксировать в BRD единицу и смысл. Затрагивает расчёт баллов (Back: 2.7.3) — согласовать сквозно. | Этот раздел зависит от Тарифов, который еще не реализован, изменили вес требования на “2”. |
| OQ2.2-8 | Код BR2.2-14 | Требование говорит: правила работы с заказами берутся у площадки, а если их нет — у объекта партнёра. В коде есть побочный эффект сверх BRD: любое изменение часов площадки — как вручную, так и автоматически при изменении часов объекта — полностью очищает привязанные к площадке правила бронирования. После этого площадка молча начинает работать по правилам объекта. Тот же сигнал отвязывает площадку от цен в сервисе цен. — нужно подтверждение: ожидаемо ли, что смена часов сбрасывает настроенные правила и цены. RoomAggregate.cs:240-249, :317-324, :399-405; RoomHoursChangedPricesConsumer.cs:19-35 | Разработка | Open | (А) сохранять правила, совместимые с новыми часами, и пересобирать только конфликтующие (рекоменд., если потеря настроек партнёра нежелательна). (Б) оставить полную очистку и зафиксировать её в BRD как осознанное поведение — тогда UI обязан предупреждать партнёра до сохранения. | от Продукта: убрать побочный эффект, при изменении часов объектов не очищать правила бронирования площадки Действительно такое есть, только правила не “очищаются”, а удаляется именно привязка к площадке. Если от продукта есть ок, что такого быть не должно, то да, надо будет править |
| OQ2.2-9 | Код BR2.2-3 | Требование говорит: описание площадки — не более 500 символов. В коде ограничение длины не проверяется нигде: ни в доменной модели, ни на входе в шлюз API, ни в базе (сервис работает без миграций, ограничений на длину колонки не заводится). Описание принимается любой длины. Заодно не проверяется и пустота названия площадки, хотя у соседних сущностей того же сервиса такие проверки есть. — нужно решение: добавить проверку ≤500 и где именно. RoomInfo.cs:13-33 (присваивание без проверок); Room.cs:30-31 (колонка без длины); шлюз — проверок нет (Musbooking.ApiGateway, совпадений по проверкам нет) | Разработка (Владислав) | Open | (А) добавить проверку в конструктор значения RoomInfo — ≤500 для описания и непустое название (рекоменд.: дёшево, механизм в кодовой базе уже используется — GroupInfo.cs:12-13, OptionInfo.cs:19). (Б) зафиксировать в BRD, что порог обеспечивается только интерфейсом, — но тогда правило перестаёт быть правилом данных, чем оно объявлено в BR2.2-3. Связать с OQ2.2-20, OQ2.2-25 — общая первопричина. | От бизнеса: исправили требования, поместили его на фронт. |
| OQ2.2-10 | Код BR2.2-4 | Требование говорит: карточка площадки хранит характеристики помещения, в том числе схему площадки. В коде площадь, габариты, вместимость и параметры фильтрации есть, а поля под схему (план помещения) нет ни в доменной модели, ни в хранении — за обход сервиса площадок не найдено. Возможно, схема — это файл из раздела 9.6.1, но привязки к площадке за обход не видно. — нужно подтверждение: где хранится схема площадки. RoomInfo.cs:34-42, RoomSettings.cs:14-38 (поля схемы нет); не найдено за обход по сервису площадок | Разработка (Владислав) | Closed | (А) подтвердить у владельца раздела 9.6.1, что схема — обычный файл площадки, и отметить это в BR2.2-4 как границу раздела (рекоменд., если файлы площадки уже живут в сервисе файлов). (Б) если схема — самостоятельная характеристика (например, координаты зон), завести поле и хранение. | Загрузка всех ресурсов происходит через отдельные ручки в микросервисе Resources. Значение базы, которое возвращается через GetBases включает в себя контракт Files, в котором как раз находятся необходимые данные по ресурсам |
| OQ2.2-11 | Код BR2.2-8 | Требование говорит: карточка площадки хранит фотографии (минимум 3), видео-обзор и дополнительные видео, фото, аудио и PDF-материалы. В коде у площадки нет ни одного поля под медиа — файлы подтягиваются из сервиса файлов по идентификатору площадки при чтении карточки. Правило «минимум 3 фотографии» не обеспечивается нигде. Видео-обзор не отделён от прочих видео — это просто файл типа «видео». Отдельного типа под аудио в перечне типов файлов нет вообще, PDF попадает в общий тип «документ». — нужно решение: где обеспечивается минимум 3 фото и как различать видео-обзор и аудио. IImageService.cs:16, GetRoomsQueryHandler.cs:31-34, :59 (файлы из другого сервиса); FileType.cs:9-19 (типы: значок, изображение, видео, документ) | Разработка (Владислав) | Closed | (А) согласовать с владельцем 9.6.1: порог «минимум 3 фото» проверять при сохранении карточки, видео-обзор и аудио — выделить признаком/типом файла (рекоменд., если BRD настаивает на составе). (Б) зафиксировать в BR2.2-8 как границу: состав и пороги — зона ответственности раздела файлов, здесь только ссылка. Требует решения бизнеса, блокирует ли нехватка фото публикацию площадки. | касаемо полей под файлы см. пункт выше Проверка количества фотографий происходит на стороне фронта, сейчас не получиться добавить площадку физически, у которой меньше 3х фотографий Не совсем поняла про различие типа видео Реализации хранения аудио файлов сейчас действительно нет |
| OQ2.2-12 | Код BR2.2-10 | Требование говорит: для интеграций хранятся идентификаторы синхронизаций, подключённых к площадке. В коде таких идентификаторов у площадки нет: за обход доменной модели и хранения не найдено ни одного поля вида «внешний идентификатор» или «идентификатор синхронизации». Единственная связь с интеграциями — членство площадки в списке интерфейсов со значениями YClients, Google Calendar, AppEvent. Поле LastSync в показателях площадки — это отметка времени последнего применённого события по отзывам, а не идентификатор интеграции. — нужно решение: где хранятся идентификаторы синхронизаций. RoomStatistics.cs:44-45 (last_sync — только время); Source.cs:3-14; не найдено за обход по доменной модели и хранению площадки | Разработка (Владислав) | Closed | (А) подтвердить, что идентификаторы синхронизаций живут в сервисе интеграций, и отметить это в BR2.2-10 как границу (рекоменд., если владение интеграциями там). (Б) если BR2.2-10 закреплён за этим сервисом — завести хранение идентификаторов на площадке. | В доменной моделе площадки, которая лежит в сервисе партнёрок, действительно нет отдельного ID интеграции, НО в сервисе интеграций ID синхронизаций есть и храняться отдельно. Считать источником правды можно сервис интеграций, для площадки брать syncId из roomSync.Id или calendarSync.Idв зависимости от типа интеграции |
| OQ2.2-13 | Код BR2.2-10 | Требование говорит: площадка должна поддерживать связь с другими площадками (связанные площадки). В коде связь хранится, но она односторонняя: при сохранении площадки А со связью на Б создаётся только запись «А → Б», обратная запись «Б → А» автоматически не появляется. То есть со стороны Б связь не видна. Проверки, что связанная площадка принадлежит той же партнёрской зоне, за обход не найдено. — нужно подтверждение: связь должна быть взаимной или направленной. RoomRepository.cs:178-180, :194-197; RoomMapper.cs:55-60 (пишется только текущая площадка) | Разработка (Владислав) | Open | (А) сделать связь взаимной — создавать парную запись (рекоменд., если «связанные площадки» по смыслу симметричны, как предполагает общее расписание). (Б) оставить направленной и зафиксировать это в BRD. Детальная логика общего расписания — Back: 2.2.1, здесь только модель хранения связи. | если в BRD имелось в виду взаимные “связанные площадки”, код не соответствует. Если имелась в виду направленная настройка распространения заказов с одной площадки на другие, текущий код соответствует направленной модели, но тогда требование/названия стоит уточнить, потому что “связанные площадки” читается как симметричная связь |
| OQ2.2-14 | Код BR2.2-15 | Требование говорит: по площадке транслируются справочник привязанных позиций, список цен и список скидок. В коде цены и скидки подтверждены: они не хранятся у площадки, а запрашиваются на лету из сервисов цен и скидок при каждом чтении карточки; диапазон стоимости считается там же. А вот трансляции «справочника привязанных позиций» по площадке за обход не найдено — ни в чтении карточки, ни в ответах методов площадки. — нужно подтверждение: где транслируются привязанные позиции. RoomProcessingService.cs:191, :211 (цены и скидки из других сервисов); GetRoomsQueryHandler.cs:43 (диапазон стоимости); позиции — не найдено за обход по сервису площадок | Разработка (Владислав) | Closed | (А) подтвердить, что позиции читаются отдельным методом сервиса позиций (Back: 2.5), и отметить в BR2.2-15 как границу (рекоменд.). (Б) если позиции должны приходить в карточке площадки — добавить их в чтение. | Позиции получаются отдельной ручкой |
| OQ2.2-15 | Код BR2.2-11 | Проблема: в коде полностью написана проверка «часы площадки должны помещаться в часы объекта партнёра» — с четырьмя понятными сообщениями об ошибках и 18 тестами, которые проходят. Но эта проверка не вызывается из рабочего кода ни разу: ни при создании, ни при изменении площадки. То есть правило фактически не действует, а зелёные тесты создают впечатление, что оно работает. Частично его роль выполняет автоматическая подгонка часов площадки под часы объекта, но только при изменении объекта, а не при ручном вводе часов площадки. — нужно решение: включить проверку или удалить вместе с тестами. RoomAggregate.cs:408-471 (не вызывается); RoomAggregateValidateHoursTests.cs (18 тестов) | Разработка (Владислав) | Open | (А) подключить проверку в создание и изменение площадки, если правило нужно (рекоменд.: код готов и покрыт тестами, цена подключения минимальна). (Б) удалить метод и тесты, если подгонка часов под объект признана достаточной, — иначе тесты продолжат вводить в заблуждение. | Эта проверка имеет смысл только если будет принято окончательное решение о том, что часы работы площадки не наследуются от часов работы базы. Если часы какие угодно можно будет выставлять вне зависимости от работы базы, то проверка возможно понадобиться. Нужно обсудить с бизнесом |
| OQ2.2-16 | Код BR2.2-12 | Проблема: формат работы читается из двух разных источников. Мобильное приложение, виджет и поиск берут формат объекта партнёра, а админка и карточка площадки — собственную колонку площадки. Сейчас расхождения не видно только потому, что колонка площадки всегда перезаписывается значением объекта при сохранении. Если формат когда-либо станет собственной настройкой площадки (см. OQ2.2-3), интерфейсы начнут показывать разное. RoomReadOnlyRepository.cs:412, :578, :710, :840, :1576, :1726 (формат объекта) против :1161, :1276 (формат площадки) | Разработка (Владислав) | Open | (А) привести все пути чтения к одному источнику — тому, который выберет бизнес в OQ2.2-3 (рекоменд.). (Б) оставить как есть только если формат навсегда остаётся свойством объекта, и тогда убрать колонку у площадки, чтобы не было второго источника истины. Ждёт решения по OQ2.2-3. | Тут нужно финальное решение бизнеса по формату работы площадок |
| OQ2.2-17 | Код BR2.2-14 | Что подтверждено и что сломано: основной механизм соответствует BRD — при подборе правил набор, привязанный к площадке, имеет приоритет над набором объекта партнёра, и при отсутствии правил площадки берутся правила объекта (BookingRuleSetRepository.cs:240-245). Проблема в соседнем способе чтения тех же правил: там при запросе по площадке фильтр всё равно строится по объекту, а идентификатор площадки в условие не попадает — похоже на ошибку копирования. В результате этот путь никогда не вернёт правила конкретной площадки, и два способа чтения дают разный ответ. BookingRuleSetRepository.cs:124-129 (в ветке площадки фильтр по объекту) | Разработка (Владислав) | Закрывает PM | Закрываю сам: завести дефект «второй путь чтения правил бронирования игнорирует площадку» с указанием строк и проверить, кто вызывает этот метод → тикет в Bitrix. Продуктового выбора нет: BRD однозначен, поведение — ошибка. | Не понятно, о каком соседнем методе идет речь Скорее всего речь о GetByBaseOrRoomId, не правильно настроена там фильтрация при roomId != null, это нужно будет поменять. Он используется в GetByBaseOrRoomId и в GetByBaseOrRoomId. Но фактически этот метод не второй путь подбора правил для бронирования. Это служебный метод для поиска сетов правил, из которых надо удалить scope объекта/площадки при измененияя часов. Баг есть, надо править |
| OQ2.2-18 | Код BR2.2-4 | Проблема: габариты теряются при чтении. При сохранении длина, ширина и высота записываются по отдельности и каждая может быть пустой, а при чтении из базы габариты собираются только если заполнены все три сразу — иначе площадка читается как «габаритов нет». То есть партнёр, указавший только длину и ширину (а высоту не знающий), после перезагрузки карточки увидит пустые габариты. Это же обесценивает будущую проверку «длина × ширина = площадь» (OQ2.2-20). RoomMapper.cs:72-74 (запись по отдельности) против RoomMapper.cs:111-113 (чтение только при всех трёх) | Разработка (Владислав) | Закрывает PM | Закрываю сам: завести дефект «частично заполненные габариты теряются при чтении» → тикет в Bitrix. Продуктового выбора нет — это потеря введённых данных. Чинится тем, что каждая из трёх величин становится самостоятельно необязательной. | все ок, Можно и так заполнить только три, без этого не будет создана площадка. |
| OQ2.2-19 | Код BR2.2-6, BR2.2-7 | Проблема: в контракте создания и изменения площадки поле, которое заполняет строку райдера, называется Equipment («Список оборудования»). Само хранение корректно — это райдер-строка. Но имя параметра ровно совпадает с будущей функцией «райдер в формате списка оборудования» (BR2.2-7), которая ещё не начата, и это гарантированно будет путать при её разработке. CreateRoomCommand.cs:28 и UpdateRoomCommand.cs:29 (Equipment) → CreateRoomCommandHandler.cs:84, UpdateRoomCommandHandler.cs:117 (кладётся в райдер) | Разработка (Владислав) | Закрывает PM | Закрываю сам: завести задачу «переименовать параметр Equipment в Rider в контрактах площадки» (с согласованием с потребителями API) → тикет в Bitrix. Продуктового выбора нет — правка именования, поведение не меняется. | все ок, не мешает масштабированию |
| OQ2.2-20 | Код BR2.2-5 | Требование говорит: если заполнены длина и ширина, система проверяет, что длина × ширина = площадь (с допуском на округление до целого). В коде такой проверки нет: площадь и габариты — независимые поля, связь между ними нигде не вычисляется. Можно сохранить площадь 10 м² при габаритах 5 × 5 м. Признак незавершённого намерения: файл габаритов подключает библиотеку исключений, но не использует ни одного. — нужно решение: добавить проверку и определить допуск. RoomInfo.cs:22-32, :40-41 (площадь и габариты независимы); Dimensions.cs:10-21 (только присваивание) | Разработка (Владислав) | Open | (А) добавить проверку в конструктор значения габаритов/RoomInfo с допуском на округление (рекоменд.; сначала нужно починить OQ2.2-18, иначе проверка будет работать только при всех трёх габаритах). (Б) зафиксировать в BRD, что соответствие проверяется интерфейсом как подсказка, а не жёсткое правило. Связать с OQ2.2-9, OQ2.2-25. | Да, проверки сейчас не реализовны на стороне бэке. Нужно решить, кто в итоге будет проверять отрицательные значения: фротн или бэк |
| OQ2.2-21 | Код BR2.2-16 | Требование говорит: по площадке транслируются избранное, средний рейтинг, количество отзывов, количество заказов по источникам и диапазон стоимости. В коде подтверждены избранное, количество отзывов, средний рейтинг (и дополнительно распределение оценок 1–5), диапазон стоимости считается на лету из сервиса цен. А «количества заказов по источникам» нет нигде: ни в показателях площадки, ни в сервисе заказов — там есть разрезы «клиент × партнёрская зона» и по группам обработки, но не «площадка × источник». — нужно подтверждение: где собираются заказы по источникам. RoomStatistics.cs:13-45 (состав показателей); не найдено за обход по сервисам площадок и заказов | Разработка (Владислав) | Open | (А) уточнить у владельца разделов 9.1/9.4.1, где агрегируется показатель, и при необходимости расширить показатели площадки (рекоменд.). (Б) если показатель приходит из аналитики другого сервиса — отметить в BR2.2-16 как границу. | Сборка заказов по источникам для площадки не реализована |
| OQ2.2-22 | Код BR2.2-17 | Требование говорит: по площадке транслируются последние записи истории изменений. В коде истории нет: таблица под историю площадки объявлена, но она даже не создаётся при инициализации базы, в неё никто не пишет и никто не читает. Метода чтения истории нет ни в одном из сервисов. Данные об изменениях при этом существуют — при сохранении площадки формируется список изменённых полей со старым и новым значением, — но он уходит в сервис авторизации для проверки прав на конкретные поля, а не в журнал. — нужно решение: где ведётся история. RoomHistory.cs:10-24 (модель есть); DbInitializer.cs:63-73 (таблица не создаётся); RoomAggregate.cs:276-277, UpdateRoomCommandHandler.cs:81 (изменения уходят в авторизацию) | Разработка (Владислав) | Open | (А) реализовать историю через уже существующий сигнал об изменении площадки — он специально несёт «было/стало» и список изменений, то есть рассчитан на журнал (рекоменд., в связке с владельцем раздела 9.2). (Б) если история целиком живёт в 9.2 — отметить в BR2.2-17 как границу и удалить неиспользуемую таблицу. Внимание: в предыдущей сверке это требование было ошибочно помечено подтверждённым. | на доработку |
| OQ2.2-23 | Код вне BRD | Что нашли: у площадки есть полноценная архивация — признак «в архиве», дата архивации, операции архивирования и восстановления, отдельное право на это действие и отдельный сигнал для других сервисов. Архивация заменяет удаление: команды жёсткого удаления площадки в коде нет вовсе. При этом в BRD раздела 2.2 про архив и удаление площадки нет ни одного требования. Ограничений на архивацию тоже нет — например, площадку с активными заказами архивировать ничто не мешает. — нужно решение: зафиксировать жизненный цикл площадки в BRD. RoomAggregate.cs:279-289; Room.cs:39-43; UpdateRoomCommand.cs:37; UpdateRoomCommandHandler.cs:130 | Бизнес (Герман) | Open | (А) добавить в BRD требование о жизненном цикле площадки: архивация вместо удаления, кто вправе, что происходит с активными заказами и публикацией (рекоменд. — механизм уже работает и влияет на партнёров). (Б) если архив описан в соседнем разделе (WebLk: 4.2 управление площадками) — сослаться и не дублировать. | Обновили скоуп и требования |
| OQ2.2-24 | Код вне BRD | Что нашли: помимо архива у площадки есть второй, независимый механизм — «снятие с публикации»: он убирает у площадки публичные интерфейсы (мобильное приложение, виджет, каталог), оставляя её активной в админке. Может применяться сразу ко всем площадкам партнёрской зоны. В BRD этого механизма нет. Отдельно: в отличие от создания и изменения, эта операция не проверяет права — она внутренняя и снаружи не вызывается, но проверки в ней нет. — нужно решение: описать снятие с публикации в BRD и подтвердить отсутствие проверки прав. RoomAggregate.cs:294-301; TakeOffRoomsCommandHandler.cs:27-62 (проверки прав нет); RoomAggregate.cs:40-43 (публичные интерфейсы) | Бизнес/Разработка (Герман → Владислав) | Open | (А) описать в BRD два разных состояния — «в архиве» и «снята с публикации» — и кто/когда их применяет (рекоменд.: сейчас они смешиваются, а для партнёра это разные вещи). (Б) если снятие с публикации — исключительно служебный механизм (например, при задолженности), отметить это и оставить вне BRD. Разработке: подтвердить, что операция навсегда останется внутренней, иначе добавить проверку прав. | По идее, снятие публикации может производиться только менеджером. ABAC проверку эту будет закрывать. Но снятие по идее идет только из сервисного кабинета. Это нужно уточнить у бизнеса |
| OQ2.2-25 | Код вне BRD | Что нашли: числовые характеристики площадки не имеют никаких границ. Длина, ширина, высота, площадь и вместимость принимают любые значения, включая отрицательные и ноль; процент баллов принимает и отрицательные значения, и больше 100. В BRD границы не заданы, но отрицательная высота потолков или вместимость −5 человек явно не предполагались, а процент баллов больше 100 напрямую влияет на расчёт баллов в заказах. — нужно решение: задать допустимые диапазоны. Dimensions.cs:12-20 (проверок нет); RoomInfo.cs:37, :40, :42 (процент баллов, площадь, вместимость без проверок) | Разработка (Владислав) | Open | (А) добавить проверки в конструкторы значений: неотрицательность размеров и вместимости, процент баллов в диапазоне 0–100 (рекоменд.: механизм в кодовой базе уже есть — FeatureInfo.cs:12 использует такую проверку; закрывается заодно с OQ2.2-9 и OQ2.2-20). (Б) оставить проверки интерфейсу — но тогда данные защищены только пока никто не обратится к API напрямую. Границу процента баллов согласовать с Back: 2.7.3. | Да, если сейчас проверки отсутствуют, то нужно будет их добавить. В целом это можно сделать на стороне бэке или на стороне фронта |
| OQ2.2-26 | Код вне BRD | Что нашли: защиты от одновременного редактирования площадки нет. У площадки есть поле версии, оно сохраняется и читается, но нигде не увеличивается и не проверяется — при создании всегда 0. Если два сотрудника партнёра одновременно редактируют одну площадку, изменения того, кто сохранит первым, будут молча затёрты вторым. В BRD требований на этот счёт нет. — нужно решение: нужна ли защита от одновременного редактирования. RoomAggregate.cs:101, :144; RoomMapper.cs:48, :133 (версия сохраняется, но не растёт) | Разработка (Владислав) | Open | (А) задействовать поле версии по назначению: увеличивать при сохранении и отклонять сохранение по устаревшей версии (рекоменд. — поле уже есть и хранится, задумка очевидна, но не доведена). (Б) если одновременное редактирование в реальности не встречается — удалить поле версии, чтобы оно не выглядело работающим механизмом. | Надо потестировать одновременное обновление комнаты. В идеале, да, нужно будет довести версионирование до ума |
| OQ2.2-27 | Код вне BRD | Проблема: технический мусор вокруг площадки, который вводит в заблуждение при чтении кода. (1) При создании площадки в доменную модель передаётся параметр «приоритет», который никуда не записывается и до хранения не доходит — поля приоритета у площадки нет вовсе. (2) Объявлены и подключены к площадке таблицы отзывов и медиа объекта, которые не создаются, не пишутся и не читаются. (3) Пять методов чтения помечены как неиспользуемые, но по-прежнему открыты наружу и вызываемы, причём один зарегистрирован сразу под двумя именами. RoomAggregate.cs:67, :183, CreateRoomCommandHandler.cs:86 (приоритет); RoomReviews.cs:10-11, BaseMedia.cs:10-11 (мёртвые модели); GetRoomInfosQuery.cs:7-8, GetSharedRoomsByRoomIdQuery.cs:7-8, GetRoomBasicInfoQuery.cs:8-10, GetRoomPlacementConditionsQuery.cs:6-7, SearchHotQuery.cs:12-13 | Разработка (Владислав) | Закрывает PM | Закрываю сам: завести задачу на техуборку — удалить мёртвый параметр приоритета и неиспользуемые модели, закрыть или задокументировать устаревшие методы API → тикет в Bitrix. Продуктового выбора нет, поведение не меняется. | Запланирована уборка. |
| OQ2.2-28 | Код BR2.2-7 | Требование говорит: райдер в формате списка оборудования (категория, наименование и модель, габариты, фотография, инструкция) — реализация после релиза; модель хранения требует подтверждения. В коде такой структуры нет: райдер — одна плоская строка, дочерних сущностей у площадки не существует. Это ожидаемо для пострелизной функции, вопрос — только о модели хранения, которую BRD сам просит подтвердить. — нужно решение: через дополнительные позиции или отдельный справочник. RoomInfo.cs:38, Room.cs:33-34 (райдер — строка); структура списка оборудования не найдена за обход | Разработка (Владислав) | Open | (А) отдельный справочник оборудования площадки — если позиции райдера не продаются и не участвуют в заказе (рекоменд.: по составу полей из BRD — категория, модель, инструкция — это описание, а не товар). (Б) через дополнительные позиции (Back: 2.5) — если оборудование должно попадать в заказ и стоить денег. Решение нужно до старта разработки; сейчас статус «не начато». | тут есть несколько вариатов реализации. Если речь идет об оборудовании как в текущем кабинете, то это все как будто бы можно закидывать в таблицу оборудование |
| OQ2.2-29 | Код BR2.2-13 | Требование говорит: отдельные режимы и форматы работы площадки по условиям — периоды действия, опции, диапазоны опций, дни недели, время — реализация после релиза. В коде функции нет, и это ожидаемо. Но есть ловушка: существует сущность с похожим названием «условие площадки», которая на самом деле совсем про другое — про стоимость, скидку, кэшбек и лимиты по городам и сферам, то есть про условия размещения. Ни периодов, ни дней недели, ни времени, ни режимов в ней нет. При этом она полностью мертва: у неё нет ни хранения, ни обработчиков, ни регистрации — её вытеснила рабочая сущность «условие размещения» с тем же составом полей. — нужно подтверждение: считать функцию не начатой и не принимать однофамильца за реализацию. RoomConditionAggregate.cs:13-24 (стоимость/скидка/кэшбек/лимиты); PlacementConditionAggregate.cs:11-25 (рабочий двойник) | Разработка (Владислав) | Закрывает PM | Закрываю сам: зафиксировать статус BR2.2-13 «не начато» и завести задачу на удаление мёртвой сущности «условие площадки», чтобы её не приняли за задел под это требование → тикет в Bitrix. Сроки самой функции — за планированием релизов. | |
| OQ2.2-30 | Код BR2.2-1 | Что подтверждено: площадка хранится как самостоятельная сущность с обязательной привязкой к объекту партнёра. Привязка обязательна (поле не допускает пустого значения), существование объекта проверяется при создании, партнёрская зона копируется из объекта. Связь неизменяема: перенести площадку в другой объект нельзя — такого параметра в изменении нет. Нюанс без последствий для требования: связь не подкреплена ограничением целостности в базе (сервис работает без миграций), она держится проверкой в коде. RoomAggregate.cs:38, :146; CreateRoomCommandHandler.cs:61-63, :78-79; Room.cs:22-23, :61-62 | Разработка | Подтверждено | ||
| OQ2.2-31 | Код BR2.2-6 | Что подтверждено: райдер площадки хранится как текстовое описание — отдельной строковой колонкой, сквозная цепочка от контракта API до базы прослежена. Формат содержимого не ограничивается, поэтому HTML-разметка сохраняется как есть, что соответствует требованию. RoomInfo.cs:38; Room.cs:33-34; RoomMapper.cs:46 | — | Подтверждено | Расхождения нет. Именование параметра в контракте — см. OQ2.2-19. |