Направление работ: Back Код раздела: 1.2 Аккаунты и пользователи > Организация доступа к системе Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 22.06.26
1. Назначение
Организация доступа определяет, какие зоны системы доступны Аккаунту и какие действия он может выполнять в каждой зоне.
Система хранит связь доступа с зоной, тарифом, ролью и категорией права, а затем использует эти данные при проверке операций.
Документ фиксирует модель доступа на уровне системы; детальные матрицы ролей, тарифов и интерфейсные сценарии описываются в соседних разделах.
2. Ключевые понятия
Доступ — список прав и разрешений, которые определяют, какие действия пользователь может выполнять в системе.
Зона доступа — область действия прав: клиентская зона, партнерская зона или сервисная зона.
Клиентская зона — зона базовых и расширенных клиентских возможностей для управления своими данными и заказами.
Партнерская зона — зона управления площадками, бронированиями и операционной деятельностью конкретной партнерской зоны.
Сервисная зона — зона управления системой и глобальными настройками.
Роль — набор прав, который определяет доступ пользователя в партнерской или сервисной зоне.
Тариф — условие, которое открывает доступ к клиентской или партнерской зоне и может расширять набор прав.
Категория права доступа — справочная характеристика права, которая определяет формат реализации возможности в системе.
3. Scope
Входит
- S1 Зоны доступа: клиентская, партнерская и сервисная зоны, а также область действия доступа в каждой зоне.
- S2 Тарифы и роли: выдача доступа через тарифы в клиентской и партнерской зонах и через роли в партнерской и сервисной зонах.
- S3 Права доступа: категории прав доступа и единый список прав доступа — таблица.
- S4 Проверка и расширение доступа: проверка права перед выполнением операции, отказ доступа и возможность расширения прав без привязки к интерфейсу.
Не входит
- Back: 1.1 Организация Аккаунтов, учетные данные и токены доступа
- Back: 1.2.1 Группировка прав по ролям и тарифам
- Back: 1.3.1 Клиентская зона доступа
- Back: 1.4.1 Партнерская зона доступа
- Back: 8.1 Настройка доступа к сервисной зоне
- Back: 8.3.1 Доступ и комиссия
- Back: 8.3.4 Подписки
- WebLk: 3.6 Сотрудники и доступ
- AdmLk: 3.7 Сотрудники и доступ к сервисной зоне
- Mobile: 5.6 Подписки
- Catalog: 4.1.3 Работа с подписками
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: #BR1.2-1 | Один Аккаунт может иметь Доступ в нескольких зонах одновременно | Бизнес | 1 | ||
| S1: #BR1.2-2 | Доступ должен применяться только в границах своей зоны действия | Область действия: * клиентская зона — конкретный клиент * партнерская зона — конкретная партнерская зона * сервисная зона — сущности и элементы системы в пределах сервисной роли | Системное | 1 | |
| S1: #BR1.2-3 | Доступ Аккаунта в партнерской зоне должен ограничиваться разрешенными ему партнерскими зонами и базами (ABAC) | Доступ применяется по иерархии партнерская зона > база. Доступ к зоне означает доступ ко всем ее базам, если область доступа не сужена. | Бизнес | 1 | |
| S2: #BR1.2-4 | Доступ в клиентской и партнерской зонах должен выдаваться на основании активного тарифа | Тариф определяет доступность зоны и может расширять набор прав: * клиентская зона — Клиент или Про-клиент * партнерская зона — партнерские тарифы | Бизнес | 1 | |
| S2: #BR1.2-5 | Доступ в партнерской и сервисной зонах также должен определяться ролью пользователя | Область применения роли: * партнерская зона — Владелец партнерской зоны или Сотрудник партнера * сервисная зона — Владелец сервиса или Сотрудник сервиса. В сервисной зоне доступ выдается только через роль, без тарифа. | Бизнес | 1 | |
| S3: #BR1.2-6 | Каждое право доступа должно иметь категорию права | Допустимые категории: * UI — визуальное представление функционала без операций с системой * C — создание * R — чтение * U — редактирование * A — архивация * D — удаление * DB — формат и состав данных, выдаваемых системой | Системное | 1 | |
| S3: #BR1.2-7 | Система должна использовать единый список прав доступа как источник для проверки операций | Полный список прав доступа ведется в отдельной таблице и должен быть перенесен в BRD в формате Markdown по итогу реализации. | Системное | 1 | |
| S3: #BR1.2-8 | Отдельные права доступа должны выделяться для операций с самостоятельным бизнес-правилом или тарифным ограничением (ABAC) | Кандидаты на детализацию: отмена по правилам и без правил, действия с заказами в зависимости от их статусов, перенос заказа, платные режимы цен и календаря, абонементы, Open API. | Бизнес | 1 | |
| S3: #BR1.2-9 | Отмена заказа должна управляться базовым правом отмены и дополнительными правами для выбранных условий отмены (ABAC) | Базовая отмена по правилам требует отдельного права отмены. Условия по штрафу и предоплате требуют дополнительных прав, например отмену без штрафа или удержание предоплаты. | Бизнес | 1 | |
| S4: #BR1.2-10 | Перед выполнением операции система должна проверять право Аккаунта на эту операцию | Проверка учитывает зону доступа, область действия доступа, тариф или роль и категорию права. | Системное | 1 | |
| S4: #BR1.2-11 | Перенос заказа на другую площадку должен выполняться только при наличии доступа к исходной и целевой области заказа (ABAC) | Для изменения базы проверяется доступ и к старой, и к новой базе. | Бизнес | 1 | |
| S4: #BR1.2-12 | Если право не найдено или не действует в нужной зоне, система должна отказать в выполнении операции | Системное | 1 | ||
| S4: #BR1.2-13 | Система должна поддерживать расширение прав доступа без жесткой привязки к интерфейсу (после релиза реализация) | Один интерфейс может поддерживать работу прав из нескольких зон доступа. Например, при входе в виджет партнер видит партнерский функционал и права доступа к виджету, а клиент использует клиентский сценарий бронирования. | Системное | 3 |
5. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус |
|---|---|---|---|---|
| #OQ1.2-1 | Гайдбук | Подтвердить, что полный список прав доступа в таблице актуален и может быть перенесен в BRD в формате Markdown по итогу реализации | Back-команда | Open |