Комбинация прав
Last updated
Last updated
В основе объединения правил лежит принцип приоритета привилегий.
Видеть < Изменять < ... < Администрировать
Привилегии в списке выстроены по приоритетам. Каждая последующая включает возможности всех предыдущих. Например, привилегия «Удалять записи» разрешает видеть, изменять и удалять все записи, а также создавать новые.
Вывод: если для сотрудника есть правило «видеть все записи» и одновременно действует другое правило «изменять все записи», то сотрудник сможет изменять записи.
Отдел < Каталог < Вид < Запись
Правила могут быть назначены на отдел, каталог, вид или отдельные записи. Правила для одного и того же субъекта (сотрудник или правовая группа) объединяются по приоритету вложенности. То есть правило на запись перезатирает правила на виды. Правила на виды перезатирают правило на каталог. Правило на каталог затирают правило на отдел.
Если для сотрудника походят правила нескольких субъектов (например, нескольких правовых групп), то их правила не перезатирают друг друга. Такие правила объединяются по приоритету привилегий — сотрудник получит максимальную из привилегий для подходящих субъектов.
Вывод: если для сотрудника на отдел назначена привилегия «Изменять все записи», а на каталог — «Видеть все записи», то сотрудник сможет только видеть записи.
Правила могут быть назначены на сотрудника или правовую группу. Все эти правила равнозначны и имеют одинаковый вес. Приоритет определяется привилегиями и иерархией вложенности.
Вывод: если для правовой группы «Все сотрудники» назначено правило «Изменять все записи», а для сотрудника только «Видеть все записи», сотрудник сможет изменять записи.
Правила в окне назначения доступа приведены списком. Приоритет правил не зависит от очерёдности правил. Приоритет определяется привилегиями и иерархией вложенности.
Право редактировать поле старше запрета редактировать поле. Право редактировать всю запись без исключения по полям старше права с исключениями. Подробнее в статье «Права на поля».
Однако, действует приоритет иерархии. Это значит, что если для одного субъекта есть разные права на редактирование поля на каталоге и на виде, то право на редактирование конкурентного поля будет применено от правила вида.
Вывод: если права на каталог запрещают редактировать поле, а на вид разрешает, то сотрудник сможет менять значение поля.
Алгоритм построения списка доступных записей каталога отличается, когда есть разрешающие правила на каталог (или отдел) и когда их нет.
Если для сотрудника есть подходящее правило на каталог или отдел с привилегией «Видеть все записи» или выше, то он получит доступ на все записи каталога. Исключение составляют записи с привилегией «Нет доступа» или попадающие под условия запрещающих правовых видов с привилегией «Нет доступа».
Если для сотрудника нет подходящих правил ни на каталог, ни на отдел, то он увидит лишь записи попадающие под разрешающие правовые виды или с индивидуальными разрешающими правами на записи. При этом будут также скрыты записи с привилегией «Нет доступа» или попадающие под условия запрещающих правовых видов с привилегией «Нет доступа».
Сложный кейс. Если для сотрудника нет подходящих правил на каталог, но есть на отдел и вид, то правила на вид перезатрут правила каталога (правила наследуемые с отдела) на те записи , которые попадают в этот вид. А для остальных записей каталога будут применены правила каталога, которые наследуются с отдела. Сотрудник увидит все записи каталога, а на записи попадающие в вид получит расширенные (или наоборот ограниченные) правила вида. При этом будут также скрыты записи с привилегией «Нет доступа» или попадающие под условия запрещающих правовых видов с привилегией «Нет доступа».
Алгоритм построения списка записей правового вида не зависит от прав на каталог и отдел.
Если для сотрудника есть подходящее правило на правовой вид, то записи этого вида будут доступны сотруднику. При этом из списка будут также записи с привилегией «Нет доступа» или попадающие под условия других запрещающих правовых видов с привилегией «Нет доступа».
Запись будет доступна сотруднику, если есть подходящее разрешающее правило на отдел, каталог, вид (в который попадает запись) или саму запись.
Запись не будет доступна сотруднику, если нет ни одного подходящего разрешающего правила.
Сотрудник видит и может изменять все записи в каталоге. Может создавать новые записи, удалять и назначать права.
Пример использования:
В небольших компаниях или отделах, где все сотрудники видят всё
Руководитель отдела
Как настроить:
Сотрудник видит и может изменять уже созданные записи, но не может создавать новые.
Пример использования:
В каталогах, куда данные попадают автоматически. Например, заявки с сайта.
В отделах, где регистрирует данные выделенный сотрудник
Как настроить:
Сотрудник видит записи, где он назначен как ответственный. Для этого создан правовой вид с фильтром по полю типа сотрудник и значением [Я / Смотрящий].
Пример использования:
История своих звонков, когда данные о звонках вносятся автоматически
Список персональных распоряжений и указов
Как настроить:
Сотрудник видит и может изменять записи, где он назначен как ответственный. Для этого создан правовой вид с фильтром по полю типа сотрудник и значением [Я / Смотрящий].
Пример использования:
Отдел продаж, где сотрудники работают независимо по назначенной им базе
Отдел поддержки, где заявки распределяются между сотрудниками
Список делегированных задач
Как настроить:
Сотрудник видит все записи каталога, а те, где он назначен как ответственный — может изменять. Для этого создан правовой вид с фильтром по полю типа сотрудник и значением [Я / Смотрящий].
Пример использования:
Отдел продаж, где все видят общую базу, но работают по распределенным на них заказам
Как настроить:
Сотрудник видит и может изменять записи, где он назначен как ответственный. Для этого создан правовой вид с фильтром по полю типа сотрудник и значением [Я / Смотрящий].
Пример использования:
Отдел продаж, где каждый работает со своим списком клиентов, которых вносит сам
Распределение базы клиентов по городам или филиалам
Как настроить:
Сотрудник может изменять структуру каталога, раздавать права, создавать правовые виды.
Пример использования:
Администратор компании
Руководитель отдела
Как настроить:
Скрытие каталога от сотрудника без потери доступа к данным при условии, что права описаны ниже по иерархии. Каталог визуально скрывается, но сотрудник может использовать данные в каталоге. Возможно скрыть только связанные между собой каталоги.
Пример использования:
Отдел продаж, где каждый работает с разными списками данных
Как настроить:
