Модель ролей

Роли в Raito намеренно простые. Понимание модели избавляет от сюрпризов, особенно вокруг того, кто что может выдать.

Одна роль на пользователя, без иерархии

У каждого пользователя ровно одна сохранённая роль (или ни одной). Роли плоские: нет порядка, в котором owner «включает» administrator. Роль-фильтр проходит, только если сохранённая роль пользователя совпадает с ней. Поэтому вы пишете OWNER | ADMINISTRATOR | MODERATOR и перечисляете каждую роль, которая должна проходить, ведь ни одна не подразумевает другую.

Значит, | это ИЛИ по ролям, и это единственный нужный комбинатор: при одной роли на пользователя И (AND) никогда бы не совпало.

Роли как фильтры

Встроенная роль вроде OWNER это объект-фильтр. Когда aiogram её вычисляет, она спрашивает у менеджера ролей, есть ли у текущего пользователя этот slug роли, используя id бота и id пользователя. Так как Raito регистрирует себя в контексте диспетчера, эта проверка доступна каждому хендлеру и фильтру через внедрение зависимостей.

Те же фильтры несут и метаданные (эмодзи и подпись роли) во флагах, которые читает register_commands(), чтобы настроить меню команд под каждого пользователя.

Где хранятся роли

Провайдер вы никогда не создаёте напрямую. Raito выбирает его по переданному FSM-хранилищу storage:

• MemoryStorage → в памяти (теряется при перезапуске);

• JSONStorage → файл JSON;

• хранилище Redis → Redis;

• хранилище SQLite / PostgreSQL → таблица SQL.

Все провайдеры реализуют один интерфейс IRoleProvider, поэтому остальная система не зависит от бэкенда. Память и JSON для разработки; при production=True Raito предупредит об их использовании.

Разработчики особенные

ID пользователей, переданные в developers, неявно держат роль developer без всякой записи в бэкенде. Так вы даёте доступ себе, пока никакая роль ещё не назначена.

Оговорка про эскалацию

Назначение плоское, и у этого есть последствие для безопасности, которое стоит проговорить прямо: любой, кто может управлять ролями (developer, owner или administrator), может выдать любую роль кому угодно, включая owner и developer. Единственные встроенные ограничители: нельзя менять свою роль и не-управляющий не может назначать вовсе, но два администратора могут повысить друг друга.

Так как developer может включить инструменты выполнения кода .rt eval / .rt bash (когда бот это разрешил через enable_dangerous_commands=True), относитесь к управляющим ролям как к уровню доверенного оператора. Если нужна более строгая политика (настоящая иерархия или «только owner выдаёт owner»), унаследуйтесь от RoleManager и проверяйте это в assign_role.