Направление работ: Back Код раздела: 1.2.1 Аккаунты и пользователи > Организация доступа к системе > Группировка по ролям и тарифам Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 22.06.26
1. Назначение
Группировка по ролям и тарифам определяет, через какие сущности Аккаунт получает права в разных зонах доступа.
Система использует Подписку, Тариф доступа, Партнерскую роль и Сервисную роль как способы группировки и передачи прав.
Документ не раскрывает зоны доступа и полный список прав; эти правила описаны в соседних разделах.
2. Ключевые понятия
Группировка по ролям и тарифам — правила, по которым права доступа группируются и передаются Аккаунту через тарифы и роли.
Аккаунт — цифровое представление пользователя в системе, которому могут быть выданы права доступа.
Подписка — сущность, которая определяет права доступа клиента в клиентской зоне.
Тариф доступа — сущность, которая определяет права Партнера в рамках его партнерской зоны.
Партнерская роль — набор прав для передачи сотрудникам Партнера в рамках конкретной партнерской зоны.
Сервисная роль — набор сервисных прав для передачи аккаунтам сотрудников платформы МАРТ.
3. Scope
Входит
- S1 Группировка прав по зонам: через какие сущности Аккаунт получает права в клиентской, партнерской и сервисной зонах.
- S2 Сущности группировки прав: Подписка, Тариф доступа, Партнерская роль и Сервисная роль как способы группировки и передачи прав.
- S3 Общие ограничения группировки прав: ограничения на совмещение ролей и другие ограничения, которые применяются при выдаче прав через роли и тарифы.
Не входит
- Back: 1.2 Организация доступа к системе, зоны доступа, категории прав и общая проверка доступа
- Back: 1.3.1 Клиентская зона доступа
- Back: 8.3.4 Подписки
- Back: 1.4.1 Партнерская зона доступа
- Back: 8.3.1 Доступ и комиссия
- Back: 8.1 Настройка доступа к сервисной зоне
- WebLk: 3.6 Сотрудники и доступ
- AdmLk: 3.7 Сотрудники и доступ к сервисной зоне
- Mobile: 5.6 Подписки
- Catalog: 4.1.3 Работа с подписками
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: #BR1.2.1-1 | Права Аккаунта должны группироваться в зависимости от зоны доступа через соответствующие сущности | Сущности группировки: * клиентская зона — Подписка * партнерская зона — Тариф доступа и Партнерская роль * сервисная зона — Сервисная роль | Бизнес | 1 | Частично · #OQ1.2.1-1 |
| S2: #BR1.2.1-2 | Подписка должна определять права доступа клиента в рамках всей клиентской зоны | У Аккаунта всегда активирована подписка по умолчанию для базового клиентского доступа. Подробнее Подписки описаны в Back: 8.3.4. | Бизнес | 1 | Частично · #OQ1.2.1-1 |
| S2: #BR1.2.1-3 | Тариф доступа должен определять права Партнера в рамках партнерской зоны, где он указан владельцем | Подробнее Тариф доступа описан в Back: 8.3.1. | Бизнес | 1 | Частично · #OQ1.2.1-2 |
| S2: #BR1.2.1-7 | Права Партнера в партнерской зоне не могут быть шире возможностей, открытых активным тарифом доступа (ABAK) | Если тариф неактивен, Партнеру доступны только действия для продления доступа. Расширяемые права доступны только в пределах активного тарифа. | Бизнес | 1 | Частично · #OQ1.2.1-2 |
| S2: #BR1.2.1-4 | Партнерская роль должна группировать права доступа для передачи сотрудникам Партнера в рамках его партнерской зоны | Подробнее сотрудники и доступ в партнерской зоне описаны в WebLk: 3.6. | Бизнес | 1 | Реализовано |
| S2: #BR1.2.1-8 | Партнерская роль должна определять, при каких статусах заказа пользователю доступна отмена (ABAK) | Набор разрешенных статусов хранится в настройках роли пользователя; для владельца и администратора доступен максимальный набор. Сама проверка доступа перед операцией описана в Back: 1.2, потому что относится к общей модели проверки прав. | Бизнес | 2 | Частично · #OQ1.2.1-3 |
| S2: #BR1.2.1-5 | Сервисная роль должна группировать сервисные права доступа для передачи аккаунтам сотрудников платформы МАРТ | Подробнее настройка доступа к сервисной зоне описана в Back: 8.1 и AdmLk: 3.7. | Бизнес | 1 | Реализовано |
| S3: #BR1.2.1-6 | Один Аккаунт не может совмещать роль Владельца и роль Сотрудника в рамках одной партнерской зоны | Совмещение ролей допустимо только в разных партнерских зонах: например, Аккаунт может быть Владельцем одной партнерской зоны и Сотрудником другой. | Бизнес | 1 | Не реализовано · #OQ1.2.1-4 |
5. Открытые вопросы
Пин сверки: BRD версия 0.1 (обновлено 22.06.26) · Репозиторий
booking-monorepo, веткаorigin/main, commit82359296(2026-09-07) · Дата сверки: 2026-09-08 · Якорь в коде:src/services/booking.abac(PartnerRole, ServiceRole, TariffPolicy),src/services/booking.authentication(PartnerEmployee, ServiceEmployee, Account),src/services/booking.clients(ClientTariff/ClientTariffPurchase),src/services/booking.partner-management(PartnerTariff) · Гайдбук не передан — маршрутизация вопросов без сверки с гайдбуком.
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| #OQ1.2.1-1 | Код | Требование говорит, что права клиента в клиентской зоне должны группироваться через сущность «Подписка», и что у Аккаунта всегда активирована подписка по умолчанию. В коде сущности с именем/семантикой «Подписка» (Subscription) нет вообще — полнотекстовый поиск по всему репозиторию не дал совпадений. Ближайший функциональный аналог — ClientTariff/ClientTariffPurchase в booking.clients с сервисом автоназначения тарифа по умолчанию (DefaultClientTariffAssignmentService.EnsureAssignedAsync — src/services/booking.clients/src/Clients.Application/Commands/ClientTariffs/DefaultAssignment/DefaultClientTariffAssignmentService.cs:25-76), который действительно гарантирует, что у клиента всегда есть активный тариф. Но эта сущность не называется «Подписка» и не подключена к модели авторизации ABAC: поле тарифа в профиле субъекта авторизации всегда пустое для любых аккаунтов (см. src/services/booking.abac/src/Abac.Domain/Common/Dtos/AuthorizationSubjectDto.cs:31, комментарий «у клиентского тарифа нет ID для получения»). | Бизнес | Open | Подтвердить, является ли ClientTariff задуманным воплощением понятия «Подписка» из BRD (тогда синхронизировать термины) или это разные механизмы и «Подписка» для клиентской зоны ещё предстоит реализовать отдельно, включая её связь с проверкой доступа. | |
| #OQ1.2.1-2 | Код | Требование говорит, что Тариф доступа должен определять права Партнера в его партнерской зоне, и что права Партнера не могут быть шире возможностей активного тарифа. В коде политика TariffPolicy, отвечающая за это, реализована (src/services/booking.abac/src/Abac.Persistence/Policies/TariffPolicy.cs:1-69), но профиль субъекта авторизации сейчас всегда собирается с пустым тарифом (план "", IsActive=false) — это явно помечено TODO-комментариями разработчиков в двух местах сборки профиля: src/services/booking.abac/src/Abac.Persistence/Consumers/AccessTokenCreatedConsumer.cs:79-81 и src/services/booking.abac/src/Abac.Persistence/Caching/MemoryAuthorizationSubjectContextProvider.cs:122-124 («TariffPolicy пропускает проверку»). Из-за этого проверка «права не шире тарифа» сейчас фактически не работает (fail-open). | Разработка | Open | Завершить связывание тарифа партнёра с профилем субъекта, убрать fail-open условие в TariffPolicy.IsApplicable, покрыть тестом сценарий «неактивный тариф → сужение прав до продления доступа». | |
| #OQ1.2.1-3 | Код | Требование говорит, что Партнерская роль должна определять, при каких статусах заказа пользователю доступна отмена, и что набор разрешенных статусов хранится в настройках роли. В коде отдельного поля/сущности с таким смыслом (CancellableStatuses) в модели PartnerRole нет — полнотекстовый поиск не дал совпадений. Вместо этого право на отмену для каждой комбинации статус×режим («по правилам»/«без правил») выражено отдельным кодом permission в каталоге (order_reserve_cancel_by-rules/no-rules, order-paid_cancel_by-rules/no-rules, order-closed_cancel_by-rules/no-rules — операция CancelOrder, src/services/booking.abac/src/Abac.Persistence/Migrations/20260825101541_OperationsSeedV3.cs:743-746), и то, какие статусы доступны роли, определяется тем, какие из этих кодов включены в набор прав роли. Для Владельца это отдельно подтверждено: Owner-роль получает все права каталога, включая все cancel-коды (src/services/booking.abac/src/Abac.Application/Commands/PartnerRoles/EnsureOwner/EnsureOwnerRoleCommandHandler.cs:13-85), что соответствует «для владельца доступен максимальный набор». Функционально похоже на требование, но не идентично описанной модели «набор статусов как единая настройка роли». | Разработка | Open | Подтвердить, что механизм «отдельный permission-код на каждый статус×режим» — это финальная реализация требования, и при необходимости уточнить формулировку BR1.2.1-8, чтобы она отражала фактическую модель. | |
| #OQ1.2.1-4 | Код | Требование говорит, что один Аккаунт не может совмещать роль Владельца и роль Сотрудника в рамках одной партнерской зоны. В коде явного ограничения на это не найдено: PartnerRole.IsOwner — системный флаг самой роли (src/services/booking.abac/src/Abac.Domain/Common/Models/PartnerRole.cs:24), уникальные констрейнты в БД — только на имя роли в зоне и на запись сотрудника (аккаунт+зона); ни PartnerEmployee.Create/ReplaceRoles (src/services/booking.authentication/src/Authentication.Domain/PartnerEmployees/PartnerEmployee.cs), ни IAbacRoleValidationService/RoleGrantGuard (src/services/booking.authentication/src/Authentication.Application/Common/Services/IAbacRoleValidationService.cs, src/services/booking.abac/src/Abac.Application/Commands/PartnerRoles/RoleGrantGuard.cs) не проверяют, что в списке ролей сотрудника нет одновременно Owner-роли зоны и обычной роли, и не блокируют назначение Owner-роли через обычный employee-flow. | Разработка | Open | Подтвердить: (а) ограничение не гейтится кодом осознанно, потому что Owner-роль системная и не выдаётся вручную через обычный флоу приглашения сотрудников (тогда синхронизировать BRD, указав процессный способ достижения инварианта), либо (б) нужна точечная проверка в коде. |