ERP Platform Docs

Roles

время чтения ~3 мин.

Ролевая модель

Переработано в BR 1.4.4

Enum employees.role (admin_franchise / admin_franchisee / manager / cashier) удалён. В системе теперь один слой — permissions-роли (объекты с настраиваемыми правами). См. Роли.

У сотрудника больше нет отдельного поля «роль». Есть набор назначенных permissions-ролей (каждая со своим набором ТТ) и вычисляемый scope — на какие данные он смотрит. Scope определяется не ролью, а владением юрлицом + назначенными магазинами.

Три сценария scope сотрудника

(Введено в BR 1.4.4 §2)

Во всех сервисах (Store, Catalog, Warehouse, Order, User) scope считается по единому правилу:

УсловиеScopeТипичный пример
user = legal_entities.owner_user_id И это ЮЛ имеет type=franchiseВся франшиза — все ТТ, все ЮЛ, все сотрудники в рамках franchise_idВладелец бренда (единственный главный ЮЛ)
user = legal_entities.owner_user_id И это ЮЛ имеет type=franchiseeСвои ЮЛ + их ТТ + их сотрудники (у одного владельца может быть несколько ЮЛ)Партнёр-франчайзи
Прочие сотрудникиТолько ТТ из employee_role_stores — объединение всех назначенных permissions-ролейМенеджер зала, кассир, бариста, курьер

Приоритет: type=franchise → type=franchisee → обычный сотрудник.

Нет enum в JWT

Сервисы не полагаются на поле role в JWT. Scope получают через internal endpoint User Service (с кэшем в Redis), permissions — через собственный эндпоинт permissions.

Системная роль «Администратор»

(Подробно описана в Роли)

  • Одна на франшизу, автосоздаётся при bootstrap
  • Полный набор permissions включая pos.access
  • Неудаляема, права не редактируются
  • Выдаётся владельцу франшизы при bootstrap (см. §8 BR 1.4.4)
  • Может быть выдана владельцу партнёра — если админ выбирает режим «Полный доступ» при создании ЮЛ (см. Юридические лица)

Разница между владельцами франшизы и партнёра определяется не ролью (у обоих может быть «Администратор»), а scope: owner_user_id + type ЮЛ.

Флаг типа франшизы franchises.type

(Введено в BR 1.4.4 §3)

ЗначениеПоведение
corporateПолноценная франшиза: раздел «Юр. лица» виден, можно создавать партнёров (ЮЛ type=franchisee), есть иерархия владения
individualИП: одно главное ЮЛ, раздел «Юр. лица» скрыт в UI. API блокирует создание партнёров → 403 FRANCHISE_TYPE_INDIVIDUAL

Default при создании новой франшизы — corporate. Изменение после старта — вручную SQL. Подробнее: Франшизы.

POS-авторизация

(Переработано в BR 1.4.4 §4)

PIN-логин на POS разрешён если:

  1. PIN совпадает с pin_hash сотрудника ТТ
  2. В агрегате permissions-ролей сотрудника есть pos.access

Иначе — 403 POS_ACCESS_DENIED. Enum cashier больше не используется.

У владельца франшизы и владельца партнёра (системная «Администратор») — pos.access входит в набор, поэтому они могут логиниться на POS своих ТТ при наличии pin_hash.

JWT-payload

(Обновлено в BR 1.4.4)

{
  "sub": "user_id",
  "franchise_id": "uuid",
  "role_ids": ["uuid"]
}
  • Поле role (enum) удалено
  • Поля store_ids, legal_entity_id больше не кладутся в JWT — scope считается на бэке по правилам выше (с Redis-кэшем)
  • Permissions в JWT не кладутся — отдаются отдельным endpoint’ом (см. Роли)

Правила создания сотрудников

  • Системные роли (владельцы) не создаются через форму «Сотрудники»:
    • Владелец франшизы создаётся вручную при bootstrap (SQL)
    • Владелец партнёра создаётся в одной транзакции с ЮЛ партнёра (см. Юридические лица)
  • Обычные сотрудники — через форму «Сотрудники» (создаёт владелец франшизы или владелец партнёра в рамках своего scope)

Новые permissions модулей (после BR 1.4.4)

Permission-каталог пополняется по мере появления BR. Полный список — в User Service Data Model и Роли. Краткая навигация по последним добавкам:

PermissionsМодульИсточник
kds.access, kds.settings.editKDSBR 5.1
customers.create_quick, customers.deleteCRMBR 3.1
integrations.read, integrations.manageИнтеграцииBR 2.5
marketing.read, marketing.writeМаркетинг (Standby-карусель)BR 6.1
agent.use, agent.configAI-агент (OpenClaw)BR 6.3

Ссылки

Вид графа

Обратные ссылки