1. Доступы

Разделение доступов к конкретной организации на платформе Kroncl строится на четырёх сущностях:

• аккаунт
• приглашение
• должность (роль)
• разрешение

Kroncl реализует классическую модель RBAC (Role-based access control), объединяя её возможности с модулем «Управление персоналом».

Важно отметить, что разделение прав в компании тесно связано именно с этим модулем: роль в классическом понимании заменяется записью о сотруднике в связке с должностью, для которой можно расширять базовую гостевую роль.

1.1 Аккаунт

Аккаунт — учётная запись пользователя на платформе Kroncl. Возможности аккаунта подробно рассматриваются здесь.

1.2 Роль

Kroncl предоставляет две основные (базовые) роли:

• владелец/администратор: инициатор пространства организации;
• гость: только чтение.

Наличие только двух ролей объясняется тем, что Kroncl по своей сути подменяет классическое понятие роли понятием должностей сотрудников.

При этом сотрудник не обязан иметь зарегистрированный аккаунт — это позволяет организациям вести учёт сотрудников без их личного присутствия на платформе. Таким образом, запись сотрудника в модуле управления персоналом не равна аккаунту пользователя Kroncl.

Такая модель особенно актуальна для организаций, где централизованный учёт ведут менеджеры.

Это крайне важный и довольно сложный для восприятия аспект платформы, дающий максимальную гибкость в учёте штата сотрудников. В этом разделе мы выстроим иерархию наследования разрешений для лучшего понимания, но для начала ознакомимся с понятиями приглашение и разрешение.

1.3 Приглашение

Чтобы включить аккаунт пользователя в пространство организации, достаточно отправить приглашение на корпоративную почту, привязанную к его аккаунту. При инициализации приглашения вы можете выбрать базовую роль (гость/администратор), которую получит пользователь сразу после вступления в компанию.

Обратите внимание: приглашение можно отправить и до регистрации пользователя на платформе. В таком случае мы вышлем письмо о приглашении в организацию с предложением зарегистрировать аккаунт Kroncl.

Поскольку почта сотрудника уникальна в рамках общего реестра аккаунтов, после регистрации получатель увидит приглашение в личном кабинете.

Просмотр отправленных приглашений на вступление в организацию доступен в разделе «Доступы» (левая боковая панель пространства организации) на вкладке «Приглашения». Здесь же, в карточках приглашений, можно отозвать отправленное приглашение.

1.4 Разрешение

Разрешение — право пользователя на выполнение операции в рамках организации. Каждая функция каждого модуля требует наличия у инициатора того или иного разрешения.

Для обозначения разрешений используется латинский алфавит (значение каждого поясняется на русском языке). Разберём несколько примеров:

• fm.transactions.create
• fm.transactions.reverse
• wm.catalog.positions.create

Как видно из примеров, разрешение разделено на несколько смысловых частей, разделённых точкой. Количество таких фрагментов может варьироваться от 2 до 5, однако структура остаётся единой: идентификатор модуля.объект.действие. Увеличенное количество фрагментов свидетельствует о большей вложенности объекта (или группы объектов), над которым (-ой) совершается действие.

Таким образом, приведённые в примере разрешения можно расшифровать как (порядок сохраняется):

• финансовый модуль.операции.создание
• финансовый модуль.операции.отмена
• складской модуль.каталог.товарные позиции.создание

Все модули Kroncl насчитывают более 50 разрешений, перечисленных здесь.

2. Иерархия назначения разрешений

Освоив понятия разрешения, роли, приглашения и аккаунта, выстроим иерархию переопределения разрешений.

Мы уже знаем, что только вступив в организацию, аккаунт получает базовую роль (гость/администратор), указанную в приглашении.

Однако что делать, если аккаунту требуются только разрешения на изменение данных в модуле финансов?

В таком случае расширить привилегии аккаунта можно с помощью назначения конкретных разрешений напрямую, без использования ролей. Для этого в разделе «Доступы» перейдите на страницу нужного аккаунта и присвойте нужные разрешения вручную (мы предложим список доступных).

Но и этого может быть недостаточно — например, когда группа аккаунтов должна получить одинаковые разрешения на определённый модуль. В таком случае необходимо создать должность в модуле управления персоналом, определить для неё список доступных разрешений, создать записи сотрудников, назначить их на нужную должность и привязать к ним соответствующие аккаунты.

Таким образом, аккаунты наследуют все разрешения должности сотрудника, которому назначен целевой аккаунт, объединяя их с разрешениями, назначенными конкретному аккаунту, и разрешениями на просмотр от гостевой роли.