BRD

1.4.1 Партнерская зона доступа

15 min read

Направление работ: Back Код раздела: 1.4.1 Аккаунты и пользователи > Партнеры > Партнерская зона доступа Статус: черновик Ответственный: Панкова Л.А. Версия: 0.2 Обновлено: 22.07.26

1. Назначение

Партнерская зона доступа определяет, какие операции и возможности доступны Партнеру в рамках конкретной партнерской зоны.

Система определяет состав возможностей Партнера на основании активного тарифа доступа.

Документ фиксирует только слой доступа партнерской зоны; партнерская зона как сущность, тарифы, продление доступа и роли сотрудников описываются в соседних разделах.

2. Ключевые понятия

Партнерская зона доступа — зона доступа, которая определяет операции и возможности Партнера в рамках конкретной партнерской зоны.

Партнерская зона — обособленная сущность Партнера в системе. Подробнее описана в Back: 1.4.

Аккаунт владельца партнерской зоны — Аккаунт, которому передаются права доступа после активации тарифа доступа.

Тариф доступа — тариф, параметры которого определяют возможности Партнера в рамках партнерской зоны. Подробнее описан в Back: 8.3.1.

Партнерская роль — способ группировки прав для сотрудников Партнера. Подробнее описана в Back: 1.2.1.

3. Scope

Входит

S1 Партнерская зона доступа: зона, которая определяет доступные операции и возможности Партнера в рамках конкретной партнерской зоны исходя из активного тарифа доступа.

S2 Связи и процессы доступа: обязательная связь партнерской зоны с Аккаунтом владельца, первичная активация тарифа доступа, передача полученных прав Аккаунту владельца и поддержка ролей для сотрудников партнера без раскрытия деталей процессов.

Не входит

  • Back: 1.2 Организация доступа к системе, общая модель доступа и проверка прав

  • Back: 1.2.1 Группировка прав по ролям и тарифам

  • Back: 1.4 Партнеры и партнерская зона как сущность

  • Back: 2.8 Настройки партнерской зоны

  • Back: 2.8.1 Продление доступа

  • Back: 8.3.1 Доступ и комиссия

  • WebLk: 3.2 Продление доступа

  • WebLk: 3.6 Сотрудники и доступ

4. Требования

Правила и ограничения бизнеса на уровне данных, источник истины в системе

IDТребованиеКомментарийТип требованияВесСтатус
S1: BR1.4.1-1Партнерская зона доступа должна определять доступные операции и возможности Партнера в рамках конкретной партнерской зоныСостав возможностей определяется параметрами активного тарифа доступа. Подробнее тариф доступа описан в Back: 8.3.1.Бизнес1Не реализовано \ #OQ1.4.1-1 \ #OQ1.4.1-2 \ #OQ1.4.1-3 \ #OQ1.4.1-5 \ #OQ1.4.1-8 \ #OQ1.4.1-9
S2: BR1.4.1-2Для каждой партнерской зоны должен быть определен Аккаунт владельца партнерской зоны. Партнерская зона не может существовать без владельца.Связь партнерской зоны с владельцем как часть модели сущности описана в Back: 1.4.Бизнес1— (не сверялось: требование добавлено после сверки)
S2: BR1.4.1-3Первичная активация тарифа доступа для партнерской зоны должна выполняться вручнуюПроцесс продления доступа описан в Back: 2.8.1.Системное1Не реализовано \ #OQ1.4.1-6 \ #OQ1.4.1-7 \ #OQ1.4.1-9
S2: BR1.4.1-4Партнерская зона доступа должна поддерживать передачу отдельных прав сотрудникам Партнера через ролиСостав ролей и группировка прав описаны в Back: 1.2.1.Бизнес1Не реализовано \ #OQ1.4.1-3 \ #OQ1.4.1-5

5. Открытые вопросы

Вопросы прогнаны через гайдбук 1.4.1 (+ гайдбук 1.4, разделы 2.8 / 2.8.1). Гайдбук подтвердил целевую модель «доступ = активный тариф + роли», ручную первичную активацию и передачу прав владельцу после активации — варианты «привести BRD к коду» по этим пунктам отпадают. Пробел гайдбука: раздел «Параметры и данные» в 1.4.1 отсылает к внешнему документу «Доступы» — перечня прав и возможностей в гайдбуке нет, для OQ1.4.1-1 его придётся запрашивать отдельно.

IDИсточникВопросКомуСтатусРекомендации
#OQ1.4.1-1Код BR1.4.1-1Требование говорит: состав возможностей и операций Партнера определяется параметрами тарифа доступа. В коде тариф доступа (PartnerTariffSetAggregate) несёт только коммерческие условия: скидка, условия комиссии, фиксированные условия, период, лимиты оплаты, триал. Полей возможностей/операций/функций у тарифа нет. «Возможности» (FeatureAggregate) в коде есть, но привязаны к сфере и площадке, а не к тарифу. \ PartnerTariffSetAggregate.cs:16-33; FeatureAggregate.cs:10-31; AllowFeatureOnSphere.cs:13-22Бизнес (Герман)OpenГайдбук 1.4.1 подтверждает модель: «Параметры тарифа (см. 8.3.1) определяют возможности партнёра в рамках его партнёрской зоны»; гайдбук 1.4 (2.8.1) добавляет: «Активный тариф определяет функциональные возможности в рамках партнёрской зоны». Значит связка «тариф → возможности» целевая, вариант «убрать из BRD» отпадает — это отсутствующая основа раздела, а не спорный вопрос. Осталось бизнесу: ни гайдбук 1.4.1, ни 1.4 не дают перечня возможностей — в 1.4.1 «Параметры и данные» отсылают к внешнему документу «Доступы». Решение: согласовать перечень (источник — 8.3.1 / документ «Доступы») и завести его как параметры тарифа либо явную связь «тариф → разрешённые права» (заготовка есть, см. OQ1.4.1-8).
#OQ1.4.1-2Код BR1.4.1-1Требование говорит: состав возможностей определяется активным тарифом доступа. В коде понятия «активный тариф» нет: у тарифа нет состояния активности (только срок действия From/To, флаги IsDefault/IsTrial и архивность), нет кода, выбирающего «текущий активный тариф зоны». Связь тариф↔зона — список «каким зонам разрешён тариф» (многие-ко-многим), а не указатель «активный тариф зоны». \ PartnerTariffSetAggregate.cs:17,32,33; PartnerTariffAllowedZone.cs:5-17Бизнес/РазработкаOpenГайдбук даёт опору, которой не было: «активный тариф» — реальное понятие («Активный тариф — данные тарифа, по которому активирован доступ»), и рядом есть статус продления со значениями Активен / Пролонгация / Не продлен / Архивирован. Значит вариант «убрать слово „активный“» отпадает. Но само правило вычисления активности гайдбук 1.4.1 не задаёт — он отсылает к 2.8.1 «Активация и продление доступа». Решение: зафиксировать правило активности в 2.8.1 (ровно один активный тариф на зону? по статусу продления? по сроку From/To?), затем реализовать выбор активного тарифа здесь. Связать с OQ1.4.1-9 (какая связь тариф↔зона — источник истины).
#OQ1.4.1-3Код BR1.4.1-1, BR1.4.1-4Требование говорит: зона доступа определяет возможности Партнера; роли передают отдельные права сотрудникам. В коде права хранятся и назначаются, но на операциях фактически не проверяются: единственный резолвер доступа (IsAuthorized) — заглушка, возвращающая «разрешено» всегда, на двух уровнях. Сегодня ни тариф, ни роли реально не ограничивают действия Партнёра/сотрудника. \ IdentityGrpcService.cs:21-24; IsAuthorizedQuery.cs:82-91Бизнес (Герман)OpenГайдбук подтверждает целевую модель: «Партнёрская зона доступа определяет список доступных операций и возможностей партнёра исходя из активного тарифа доступа» + «поддерживает группировку прав по ролям для предоставления отдельных прав сотрудникам». То есть «доступ = тариф + роли» — не гипотеза, а спецификация; узаконить «всё разрешено» в BRD нельзя. Осталось бизнесу: приоритет и срок включения реальной проверки. До включения слой доступа честно считать нереализованным. Та же заглушка бьёт по клиентской зоне (1.3.1/OQ1.3.1-6) — один тикет на оба раздела.
#OQ1.4.1-4Код вне BRDЧто нашли: у тарифа доступа есть поведение, которого BRD не описывает: пробный тариф (IsTrial), ограничение кратности активаций (OnlyOnce + счётчик ActivationCount) и флаг «дефолтный тариф, даётся при создании партнёрской зоны» (IsDefault, по комментарию в коде). \ PartnerTariffSetAggregate.cs:18,19,20,24Бизнес (Герман)OpenВ гайдбуке 1.4.1 про триал и лимит активаций ничего нет — подтвердить нечем. Но гайдбук задаёт дом: параметры тарифа — 8.3.1 «Доступ и комиссия», а сам раздел противопоставляет тариф подписке («в отличие от подписки, см. 8.3.4, первичная активация тарифа осуществляется вручную»). Рекомендация: отнести триал / лимит активаций / дефолтный тариф к 8.3.1 и добавить сюда перекрёстную ссылку, чтобы поведение не осталось недокументированным; в 1.4.1 не дублировать. Решение бизнеса — нужны ли они как требования вообще. Флаг «дефолтный тариф при создании зоны» пересекается с 1.4/OQ1.4-6 — связать.
#OQ1.4.1-5Код BR1.4.1-1, BR1.4.1-4Проблема: резолвер доступа IsAuthorized отключён двумя заглушками: (1) gRPC-метод сразу возвращает «разрешено», не вызывая обработчик; (2) сам обработчик первым же оператором возвращает «разрешено» (пометки // Временная заглушка, //TODO: сделать нормальную логику), остальная логика — мёртвый код. Вызывающая сторона (Цены, Партнёрские зоны и т.д.) реально шлёт запрос и кидает ошибку при «запрещено», но сервер всегда отвечает «разрешено» — ничего не блокируется. \ IdentityGrpcService.cs:21-24; IsAuthorizedQuery.cs:82-91; AuthorizationService.cs:32-39Разработка (Влад)OpenСамый срочный технический пункт: пока заглушка открыта, ни одно требование раздела не валидируется на проде. Вопрос к Владу: (А, рекоменд.) спланировать включение реальной проверки (доработать логику ролей+ресурсов, убрать ранние return true на обоих уровнях), затем сверить контракт; (Б) зафиксировать «всё разрешено» как временный режим с датой включения. Сопутствующе: есть два несведённых типа IsAuthorizedQuery (общий контракт для вызывающих vs запись в сервисе аутентификации) — при включении их нужно согласовать, иначе права/скоупы не совпадут по форме.
#OQ1.4.1-6Код BR1.4.1-3Требование говорит: первичная активация тарифа доступа выполняется вручную. В коде операции «активация» нет и нет различия «первичная активация vs продление»: создание/обновление тарифа — единый CRUD через ручные RPC-методы (CreatePartnerTariffService, UpdatePartnerTariffService); «активация» как отдельный шаг не моделируется. ActivationCount — хранимое число, не операция. \ CreatePartnerTariffCommand.cs:8; UpdatePartnerTariffCommand.cs:8; PartnerTariffSetAggregate.cs:20Бизнес/РазработкаOpenГайдбук подтверждает требование: «В отличие от подписки (см. 8.3.4) первичная активация тарифа доступа осуществляется вручную» — и отделяет её от продления, отсылая процесс к 2.8.1 «Активация и продление доступа». Значит различие «первичная активация vs продление» целевое, вариант «переформулировать под текущий CRUD» противоречит гайдбуку. Рекомендация: завести явный шаг активации (а не общий CRUD тарифа) — это закрывает формулировку BR1.4.1-3. Осталось согласовать границу с 2.8.1: что именно делает активация и чем отличается от продления.
#OQ1.4.1-7Код BR1.4.1-3Требование говорит: активация выполняется вручную. В коде автоматических путей активации нет (ни консьюмера событий, ни фонового воркера, ни платёжного триггера) — в этом смысле «вручную» не нарушено. Но «ручной» характер не гарантируется внутри сервиса: на командах создания/обновления тарифа нет проверки роли/прав, AccountId в команде — лишь аудит-штамп; ограничение «делает уполномоченный человек» полагается на шлюз/сервис аутентификации, а тот сейчас не проверяет (см. OQ1.4.1-5). \ CreatePartnerTariffCommandHandler.cs:28-53; CreatePartnerTariffCommand.cs:10Разработка (Влад)OpenРешение: где обеспечивается, что активацию выполняет уполномоченный человек. (А, рекоменд.) после включения проверки прав (OQ1.4.1-5) закрыть операции создания/обновления тарифа требованием админского права — тогда «вручную уполномоченным лицом» станет гарантией, а не допущением; (Б) если ограничение целиком на шлюзе — зафиксировать явно, где и каким правилом, чтобы «вручную» имело проверяемый адрес.
#OQ1.4.1-8Код BR1.4.1-1Что нашли: заготовка связи «тариф → разрешённые права» в коде есть — AllowPermissionToPartnerTariff (тариф↔пермишены). Но используется только как admin-настройка: фильтрует доступные пермишены по тарифу для CMS и пересобирает набор; на решении о доступе не читается (резолвер — заглушка, OQ1.4.1-5). Намерение BRD частично отражено в модели данных, но не доведено до проверки. \ AllowPermissionToPartnerTariff.cs:3-9; PermissionsRepository.cs:51-82Разработка (Влад)OpenГайдбук подтверждает связку: «Партнёрская зона передаёт аккаунту владельца полученные права доступа после активации тарифа доступа» и далее «владелец распределяет полученные права между своими сотрудниками». То есть цепочка «тариф → права → владелец → сотрудники» — целевая, и AllowPermissionToPartnerTariff ей соответствует. Продуктового вопроса нет, остался технический. Вопрос к Владу: подтвердить, что это целевой механизм, и подключить его к реальной проверке доступа (OQ1.4.1-5); передачу прав владельцу выполнять по факту активации (OQ1.4.1-6). Связать с OQ1.4.1-1.
#OQ1.4.1-9Код BR1.4.1-1, BR1.4.1-3Проблема: две несогласованные модели связи тариф↔зона. (1) У PartnerZoneAggregate есть поле TariffId, но при создании оно Guid.Empty, а Update его не меняет — поле фактически не используется. (2) Реальная связь — членство зоны в списке AllowedZones тарифа (многие-ко-многим). Какая из них «активный тариф зоны» — в коде неоднозначно. \ PartnerZoneAggregate.cs:54,174,205-353; PartnerTariffAllowedZone.cs:5-17Разработка (Влад)OpenРешение: какая связь считается источником истины. (А, рекоменд.) выбрать одну: либо довести AllowedZones + правило активности (OQ1.4.1-2) до «активного тарифа», либо начать реально заполнять PartnerZone.TariffId при активации и убрать дублирование; (Б) оставить обе, документально разведя роли (AllowedZones — «кому разрешён тариф», TariffId — «текущий активный») и заполнять TariffId при активации — менее предпочтительно, две связи легко рассинхронизируются. Пересекается с 1.4/OQ1.4-5 (активный тариф в составе данных зоны).

Вопросы по сверке с кодом

BRD 1.4.1 v0.1 · booking-monorepo · commit 9e19870 / dev/cms-conflict-warning · 2026-06-30 · якорь src/services/booking.partner-management (PartnerZones.*) + кросс src/services/booking.authentication (Authentication.*) Сводка: 9 вопросов (бизнесовых 4, программных 5); подтверждено без вопросов 0; отрезано находок 0 (все находки обратного прохода вынесены ниже)

Примечание по методу: сверка выполнена для трех требований, зафиксированных до текущего обновления; каждое имеет вес 1. Ни одно не подтверждено «чисто» — у каждого есть существенное расхождение модели или отсутствие фактической проверки. Главное сквозное расхождение (резолвер доступа IsAuthorized — заглушка return true) затрагивает сразу BR1.4.1-1 и BR1.4.1-4 и вынесено отдельным пунктом в обеих рекомендациях.

Бизнесовые

№Связано сЧто в BRDЧто в кодеГде в коде
Б1BR1.4.1-1Состав возможностей и операций Партнера определяется параметрами тарифа доступаЭто на стороне тарифа: Тариф доступа (PartnerTariffSetAggregate) несёт только условия комиссии/оплаты/периода (скидка, условия комиссии, фиксированные условия, период, лимиты оплаты, триал). Полей возможностей/операций/функций у тарифа нет. «Возможности» (FeatureAggregate) в коде есть, но привязаны к сфере и площадке, а не к тарифу. — нужно решение: что именно тариф доступа должен определять как «возможности и операции», и как это связать с тарифомPartnerTariffSetAggregate.cs:16-33; FeatureAggregate.cs:10-31; AllowFeatureOnSphere.cs:13-22
Б2BR1.4.1-1Состав возможностей определяется активным тарифом доступаТоже из Тарифов: Понятия «активный тариф» в коде нет: у тарифа нет состояния активности (только срок действия From/To, флаги IsDefault/IsTrial и архивность). Нет кода, который выбирает «текущий активный тариф зоны». Связь тариф↔зона — список «каким зонам разрешён тариф» (многие-ко-многим), а не указатель «активный тариф зоны». — нужно решение: что считать «активным» тарифом (по сроку? по флагу? один на зону?)PartnerTariffSetAggregate.cs:17,32,33; PartnerTariffAllowedZone.cs:5-17
Б3BR1.4.1-1, BR1.4.1-4Зона доступа определяет возможности Партнера; роли передают отдельные права сотрудникамПрава хранятся и назначаются, но фактически на операциях не проверяются: единственный резолвер доступа (IsAuthorized) — заглушка, возвращающая «разрешено» всегда (на двух уровнях). То есть сегодня ни тариф, ни роли реально не ограничивают действия Партнера/сотрудника. — нужно решение: подтвердить целевую модель (доступ определяется тарифом + ролями) и приоритет включения реальной проверкиIdentityGrpcService.cs:21-24; IsAuthorizedQuery.cs:82-91
Б4вне BRD—Это из тарифов: В коде у тарифа доступа есть поведение, которого BRD не описывает: пробный тариф (IsTrial), ограничение кратности активаций (OnlyOnce + счётчик ActivationCount) и флаг «дефолтный тариф, даётся при создании партнёрской зоны» (IsDefault, по комментарию в коде). — нужно решение: должны ли эти понятия (триал, лимит активаций, дефолтный тариф) попасть в требования слоя доступаPartnerTariffSetAggregate.cs:18,19,20,24

Рекомендация / варианты решения

  • Возможности vs комиссия у тарифа (Б1). Тариф доступа в коде — это коммерческие условия (комиссия/оплата/период), а BRD ждёт от него «возможности и операции».
    • Вариант А (рекоменд.): согласовать с продуктом точный перечень «возможностей и операций», управляемых тарифом доступа, и завести их как параметры тарифа (либо явную связь тариф→разрешённые операции). Закрывает разрыв между намерением BRD и моделью.
    • Вариант Б: уточнить BR1.4.1-1 так, чтобы «возможности» определялись не тарифом напрямую, а связкой «тариф → набор прав/фич» (в коде уже есть заготовка AllowPermissionToPartnerTariff — тариф↔пермишены, см. П4). Тогда BRD описывает целевую связку, а не текущее «тариф = только комиссия».
  • Определение «активного» тарифа (Б2). Без согласованного определения требование непроверяемо и нереализуемо.
    • Вариант А (рекоменд.): продукту зафиксировать правило активности (например: ровно один действующий тариф на зону, выбираемый по сроку From/To/архивности) — затем реализовать выбор активного тарифа. Без этого «состав возможностей по активному тарифу» не на что опереть.
    • Вариант Б: если «активность» намеренно не нужна (тариф один и неизменен) — упростить формулировку BRD, убрав слово «активный».
  • Реальная проверка прав (Б3) — сквозная первопричина, общая с программным блоком (см. П1). Сейчас доступ не ограничивается ничем.
    • Вариант А (рекоменд.): подтвердить целевую модель «доступ = тариф + роли» и поставить включение реальной проверки в план; до включения честно считать слой доступа нереализованным (вопрос приоритезации — за бизнесом/продуктом).
    • Вариант Б: если на текущем этапе «всё разрешено» — осознанное временное решение, зафиксировать это в BRD как явное допущение с датой пересмотра.
  • Понятия сверх BRD: триал / лимит активаций / дефолтный тариф (Б4).
    • Вариант А (рекоменд.): дополнить требования слоя доступа этими понятиями либо явно отнести их к разделу тарифов 8.3.1 — чтобы поведение не осталось недокументированным.
    • Вариант Б: оставить вне раздела 1.4.1, если это сознательно зона ответственности «Доступ и комиссия» (8.3.1); тогда добавить перекрёстную ссылку, чтобы не потерять.

Программные

№Связано сЧто в BRDЧто в кодеГде в коде
П1BR1.4.1-1, BR1.4.1-4Зона доступа ограничивает операции Партнера; права сотрудников проверяютсяРезолвер доступа IsAuthorized отключён двумя заглушками: (1) gRPC-метод сразу возвращает «разрешено», не вызывая обработчик; (2) сам обработчик первым же оператором возвращает «разрешено» (пометки // Временная заглушка, //TODO: сделать нормальную логику), остальная логика — мёртвый код. Вызывающая сторона (Цены, Партнёрские зоны и т.д.) реально шлёт запрос и кидает ошибку при «запрещено», но т.к. сервер всегда отвечает «разрешено», ничего не блокируется. — нужно решение: срок включения реальной проверкиIdentityGrpcService.cs:21-24; IsAuthorizedQuery.cs:82-91; AuthorizationService.cs:32-39
П2BR1.4.1-3Первичная активация тарифа доступа выполняется вручнуюВ коде нет операции «активация» и нет различия «первичная активация vs продление». Создание/обновление тарифа — единый CRUD через ручные RPC-методы (CreatePartnerTariffService, UpdatePartnerTariffService); «активация» как отдельный шаг не моделируется. ActivationCount — хранимое число, не операция. — нужно решение: нужна ли отдельная операция первичной активации и её отличие от продленияCreatePartnerTariffCommand.cs:8; UpdatePartnerTariffCommand.cs:8; PartnerTariffSetAggregate.cs:20
П3BR1.4.1-3Активация должна выполняться вручнуюАвтоматических путей активации тарифа в сервисе нет (ни консьюмер событий, ни фоновый воркер/планировщик, ни платёжный триггер) — в этом смысле «вручную» не нарушено. Но «ручной» характер не гарантируется внутри сервиса: на командах создания/обновления тарифа нет проверки роли/прав, команда несёт AccountId лишь как аудит-штамп; ограничение «делает админ вручную» полагается на шлюз/сервис аутентификации, а тот сейчас не проверяет (см. П1). — нужно решение: где обеспечивается, что активацию выполняет уполномоченный человекCreatePartnerTariffCommandHandler.cs:28-53; CreatePartnerTariffCommand.cs:10
П4BR1.4.1-1Возможности Партнера определяются параметрами тарифа доступаТоже из тарифов: Заготовка связи «тариф → разрешённые права» в коде есть: AllowPermissionToPartnerTariff (тариф↔пермишены). Но используется только как admin-настройка: фильтрует доступные пермишены по тарифу для CMS и пересобирает набор; на решении о доступе не читается (резолвер — заглушка, П1). То есть намерение BRD частично отражено в модели данных, но не доведено до проверки. — нужно решение: это и есть целевой механизм «тариф→возможности»?AllowPermissionToPartnerTariff.cs:3-9; PermissionsRepository.cs:51-82
П5BR1.4.1-1, BR1.4.1-3Тариф доступа определяет возможности зоны; активация привязывает тариф к зонеТоже тарифы: Две несогласованные модели связи тариф↔зона. (1) У PartnerZoneAggregate есть поле TariffId, но при создании оно Guid.Empty, а Update его не меняет — поле фактически не используется. (2) Реальная связь — членство зоны в списке AllowedZones тарифа (многие-ко-многим). Какая из них «активный тариф зоны» — в коде неоднозначно. — нужно решение: какая связь считается источником истиныPartnerZoneAggregate.cs:54,174,205-353; PartnerTariffAllowedZone.cs:5-17

Рекомендация / варианты решения

  • Резолвер доступа — заглушка (П1) — сквозная первопричина, общая с Б3. Без него ни тариф, ни роли не ограничивают действия.
    • Вариант А (рекоменд.): спланировать включение реальной проверки IsAuthorized (раскомментировать/доработать логику ролей+ресурсов, убрать ранний return true в gRPC-методе и в обработчике), затем сверить контракт. До включения слой доступа считать нереализованным.
    • Вариант Б: если «всё разрешено» — осознанный временный режим, зафиксировать это допущение в BRD и завести отдельную задачу с датой включения; не выдавать слой доступа за готовый.
    • Сопутствующе: есть два несведённых типа IsAuthorizedQuery (общий контракт в booking.domain.abstractions для вызывающих vs запись в сервисе аутентификации) — при включении проверки их нужно согласовать, иначе передаваемые права/скоупы не совпадут по форме.
  • Нет операции «первичная активация» (П2).
    • Вариант А (рекоменд.): согласовать с продуктом, нужна ли отдельная операция первичной активации, отличная от продления (раздел 2.8.1); если да — завести явный шаг активации (а не общий CRUD тарифа). Это закрывает и формулировку BR1.4.1-3.
    • Вариант Б: если «активация» = просто создание/привязка тарифа вручную, переформулировать BR1.4.1-3 в терминах существующего CRUD и убрать ожидание отдельного шага активации.
  • «Ручной» характер не обеспечивается в сервисе (П3).
    • Вариант А (рекоменд.): после включения проверки прав (П1) закрыть операции создания/обновления тарифа требованием соответствующего права администратора — тогда «вручную уполномоченным лицом» станет гарантией, а не допущением.
    • Вариант Б: если ограничение по праву обеспечивается исключительно на шлюзе — зафиксировать это явно (где именно и каким правилом), чтобы «вручную» имело проверяемый адрес.
  • Связь тариф↔зона неоднозначна (П5).
    • Вариант А (рекоменд.): выбрать один источник истины для «активного тарифа зоны». Учитывая, что PartnerZone.TariffId инертно, а рабочая связь — AllowedZones, либо довести AllowedZones+правило активности (Б2) до «активного тарифа», либо начать реально заполнять PartnerZone.TariffId при активации и убрать дублирование.
    • Вариант Б: оставить обе связи, но документально развести их роли (например, AllowedZones — «кому разрешён тариф», TariffId — «текущий активный»), и заполнять TariffId при активации. Менее предпочтительно: две связи легко рассинхронизируются.
  • Заготовка тариф→права (П4). Решается вместе с Б1/Б2: если продукт подтверждает связку «тариф → набор прав», AllowPermissionToPartnerTariff — готовый механизм, его остаётся подключить к реальной проверке (П1).

0 items under this folder.

    Graph View

    Backlinks