0010 — Ролевая модель и платформенное администрирование¶

Дата: 2026-08-21.
Статус: Принято; состав ролей дополняется последующими решениями.
Ответственный: владелец проекта.

Контекст¶

Решения 0005 и 0009 предусмотрели membership организации с ролью owner, но не разделяли права внутри организации и глобальные права разработчика SKUARO. Также требовалось зафиксировать личный кабинет пользователя и отдельный интерфейс платформенного администратора.

Решение¶

Общее правило доступа¶

Для всех пользователей SKUARO применяется ролевая модель доступа.
Роль определяет доступ к функциям, сущностям и пунктам меню.
Скрытие пункта меню не является защитой: backend отдельно проверяет право на каждое защищённое действие и чтение данных.
Платформенные роли и роли внутри организаций являются разными контурами и не подменяют друг друга.

Правило 1. `super_admin`¶

super_admin — глобальная платформенная роль разработчика SKUARO.
Роль имеет доступ ко всем функциям, сущностям и пунктам меню приложения во всех организациях без ограничений продуктовой ролевой модели.
Роль не назначается самостоятельной регистрацией и не наследуется из membership организации.
Для super_admin предусматривается отдельный dashboard /admin с разделом «Пользователи».
В разделе «Пользователи» super_admin может изменить email и статус пользователя active / inactive.
Отсутствие продуктовых ограничений не отменяет вход в систему, аудит действий, разделение сред, правила работы с секретами и инфраструктурные разрешения проекта.

Правило 2. `owner`¶

Канонический идентификатор роли внутри membership — owner; русское название в интерфейсе — «Руководитель организации».
Пользователь, который самостоятельно регистрирует новую компанию в SKUARO, получает роль owner в созданной им организации только после подтверждения email и атомарного создания Organization и Membership.
Роль действует только в конкретной организации и не даёт глобальных прав или доступа к другим организациям.
«Руководитель организации» является продуктовой ролью SKUARO и сам по себе не подтверждает юридический статус директора компании.

Правило 3. `platform_admin`¶

Канонический идентификатор глобальной роли — platform_admin; русское название — «Администратор SKUARO».
platform_admin имеет полный доступ ко всем функциям, сущностям, организациям и пунктам меню приложения, кроме защищённых операций над super_admin.
platform_admin может видеть учётную запись super_admin, но не может изменить её email, пароль, статус или роль, инициировать для неё сброс доступа, деактивировать, удалить или архивировать её.
platform_admin не может назначать или отзывать роль super_admin, включая повышение собственной роли. Управление ролью super_admin доступно только super_admin.
Ограничение применяется одновременно на frontend и backend; прямой API-запрос не может его обойти.

Личный кабинет¶

У каждого подтверждённого пользователя есть страница настроек /settings.
На первом этапе личный кабинет содержит email и управление паролем.
Значение текущего пароля никогда не отображается и не восстанавливается; интерфейс предоставляет только безопасную смену пароля.
Дополнительные поля профиля и их обязательность определяются позднее.

Последствия¶

User получает статус доступа active / inactive; отсутствие активного статуса должно блокировать вход и защищённые API-действия.
При переводе пользователя в inactive активные сессии должны быть отозваны. Это серверный security-инвариант, а не отдельное право роли.
Изменение email и статуса через /admin записывается в аудит с идентификаторами инициатора и пользователя; пароль и его производные в аудит не попадают.
Попытка platform_admin выполнить защищённую операцию над super_admin отклоняется до изменения данных и записывается как событие безопасности.
Frontend строит меню по эффективным правам, но источником истины остаётся серверная проверка.
Существующие архитектурные роли организации admin, member, viewer сохраняются как задел; их точные права и отображение ещё не приняты.
Backend, таблицы, реальные пользователи и административные операции этим решением не создаются до прохождения действующего product gate.

Отложенные вопросы¶

Матрица прав для owner, admin, member, viewer, включая доступ к сущностям и пунктам меню.
Процедура назначения и отзыва super_admin.
Процедура назначения и отзыва platform_admin.
Требования MFA, отдельного административного аккаунта и повторного подтверждения критических действий.
Процедура смены email администратором: повторная верификация адреса, уведомление пользователя и отзыв сессий.
Колонки, фильтры, поиск, журнал действий и массовые операции раздела «Пользователи».
Дополнительные поля личного кабинета.

Откат или замена¶

Изменение границы глобальных ролей super_admin и platform_admin, автоматического назначения owner или разделения платформенных и организационных ролей требует нового решения. Дополнение матрицы прав новыми ролями оформляется следующим решением без удаления этой записи.