1. Обзор ролевой модели

Обзор ролевой модели

Идея в одном предложении

Каждый пользователь имеет роль, роль — это набор прав, право даёт доступ к конкретной операции в системе. Не «галочка администратор/не администратор», а гранулярный список из ~70 разрешений, сгруппированных по модулям продукта.

Что такое право (permission)

Право — это атомарное разрешение на одну операцию. У него есть код (FLOW_MANAGE), человекочитаемое имя («Управление сценариями»), модуль (flows) и уровень (read / write / execute).

Примеры прав:

Полная карта прав по модулям приведена в главе 3 «Управление ролями и правами».

Что такое роль

Роль — это именованный набор прав. Пользователю назначается одна роль, и она целиком определяет, что он может делать в системе.

Роли бывают двух видов:

1. Системные — поставляются в составе продукта, нельзя удалить. Их можно редактировать (менять описание и набор прав), но имя зафиксировано.
2. Кастомные — создаются администратором клиента под конкретные задачи (например, «Оператор кампаний», «Маркетолог только для офферов»).

Системные роли «из коробки»

Сразу после установки или обновления в системе есть шесть системных ролей:

Сравнить роли между собой можно прямо в UI на вкладке Роли — там ✓ / × показывает, какие права есть у какой роли:

Важно про **admin**: в системе всегда должен быть хотя бы один пользователь с ролью admin. Если случайно заберёте у всех права администратора — никто не сможет управлять ролями и пользователями.

Когда какую роль выдавать

• **admin** — для тех, кто настраивает систему и управляет другими пользователями.
• **user** — для большинства маркетологов, аналитиков и операторов: они работают со сценариями, сегментами, профилями и кампаниями, но не могут менять роли и пользователей.
• **readonly** — для аудиторов, наблюдателей и руководителей: они должны видеть данные, но не должны их менять.
• **screens-\*** — узкоспециализированные роли для экрана расследований.

Если ни одна системная роль не подходит — создайте кастомную (см. главу 3).

Где живут роли и права в системе

Права и связи хранятся в БД в четырёх таблицах:

users (username) ──┐
                   ├─→ user_roles ──→ roles ──→ role_permissions ──→ permissions
                   │      M:N         (id,        M:N                 (id,
                   │                   name,                            code,
                   │                   ldap_group,                      name,
                   │                   is_system,                       module,
                   │                   is_active)                       level)
                   └─ legacy users.role (строка) — оставлена для обратной совместимости

Администратору не нужно работать с БД напрямую — все операции делаются через UI. Но если разработчики или DBA задают вопросы о составе таблиц — это они.

Что меняется по сравнению с версией 3.3.42

Подробнее об апгрейде с 3.3.42 — в опциональном разделе главы 4.

Глоссарий

• PBAC (Permission-Based Access Control) — модель доступа, при которой права назначаются ролям, а роли — пользователям. Сравните с RBAC, где роли захардкожены в код.
• Право (permission) — атомарное разрешение. Пример: FLOW_VIEW.
• Роль (role) — именованный набор прав. Пример: admin.
• Системная роль — поставляется с продуктом, нельзя удалить.
• Кастомная роль — создана администратором клиента.
• **ldap_group** — имя группы в LDAP/AD, по которому пользователи автоматически получают эту роль (см. главу 4).
• **is_system** — техническое поле в БД; true = системная роль, защищена от удаления.
• **is_active** — техническое поле в БД; false = роль недоступна для назначения. В текущем UI флаг не выставляется (только через API или БД), поэтому в повседневной работе на него не полагайтесь — для отказа от роли просто удалите её.

Дальше: Глава 2 — Управление пользователями →

↑ К содержанию руководства