1. Доступы

Чтобы понять механизм ограничения доступа в рамках компании, необходимо освоить четыре основных понятия:

• аккаунт
• приглашение
• роль
• разрешение

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

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

1.1 Аккаунт

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

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

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

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

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

Если ваша компания имеет публичный статус видимости, все пользователи платформы могут отправлять запросы на приглашение в организацию.

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

1.3 Роль

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

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

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

• гость: вступивший по приглашению.

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

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

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

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

1.4 Разрешение

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

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

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

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

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

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

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

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

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

Мы уже знаем, что только вступив в организацию, аккаунт получает гостевую роль, ограниченную операциями чтения.

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

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

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

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

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