Настройка ролей безопасности: привилегии Добавить и Добавить К

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

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

Попробуем разобраться.

1. Роль безопасности = (Привилегии на уровне записи | Привилегии на уровне задач) + Уровень доступа.
2. Привилегии на уровне записи = { Создание, Чтение, Редактирование, Удаление, Добавление, Добавление К, Назначение, Общий доступ }
3. Привилегии на уровне задач = { Отдельные специальные задачи }
4. Уровень доступа = { Нет, Пользователь, Подразделение, Головное + дочерние подразделения, Организация }

Общее правило звучит так:
Определение роли безопасности заключается в назначении привилегий на каждом уровне доступа для каждой сущности.


Пример:
Открываем Роль безопасности Продавец, находим сущность Интерес, переходим в столбец с привилегией Создание, определяем уровень доступа Пользователь. Переходим в столбец Чтение, определяем уровень доступа Подразделение. Переходим в столбец Запись, определяем уровень доступа Пользователь. Переходим в столбец Удаление, определяем уровень доступа Нет…

Все просто и понятно… пока мы не дошли до привилегий Добавление и Добавление К.

Официальный CRM дает следующее определение этих привилегий:
Добавление — привилегия, необходимая для связывания записи с текущей записью. Например, имея права на добавление для возможной сделки, пользователь может добавлять примечания к возможной сделке. То, к каким записям можно добавлять данные, зависит от уровня доступа и прав, определенных в роли безопасности.
Добавление К — привилегия, необходимая для связывания текущей записи с другой записью. Например, чтобы добавить примечание к возможной сделке, пользователь должен обладать разрешениями "Добавление к" для примечания. То, к каким записям можно добавлять данные, зависит от уровня доступа и разрешений, определенных в роли безопасности.


Проверим это на практике.

Рассмотрим пример разграничения прав по доступу к примечаниям Возможной сделки для продавца и его руководителя.

Мы хотим реализовать следующую политику безопасности: Продавец может добавлять только свои Примечания только в свою Возможную сделку. Руководитель может добавлять свои Примечания в Возможные сделки своих подчиненных.

1. Для чистоты эксперимента устанавливаем в сущностях Возможная сделка и Примечание для привилегий Создать и Запись уровень доступа Подразделение для Продавца и его Руководителя.
2. Устанавливаем в сущности Возможная сделка: у Продавца привилегия Добавление = Пользователь; у Руководителя привилегия Добавление = Подразделение.
3. Устанавливаем в сущности Примечание: у Продавца привилегия Добавление К = Пользователь; у Руководителя привилегия Добавление К = Пользователь.

Проверяем…Все работает. Отлично!

А теперь давайте поэкспериментируем: установите в Возможной сделке в роли безопасности Руководителя уровень доступа для привилегии Добавление К = Пользователь.
Теперь попробуйте добавить под Руководителем Примечание к Возможной сделке подчиненного. Получите сообщение об ошибке: недостаточно прав.

И проблема здесь лежит в правильном толковании сути привилегий Добавление и Добавление К.
Правильное определение, на мой взгляд, должно звучать следующим образом:
Привилегия Добавить К определяет право на добавление в текущую запись других записей, связанных с текущей записью отношением 1:N (где 1 – это текущая запись).
Привилегия Добавить определяет право на добавление в текущую запись других записей, связанных с текущей записью отношением N:1 (где 1 – это добавляемая запись).

Или более точно:

Привилегия Добавить К определяет право связывания текущей записи с другими записями на основе отношения 1:N.
Привилегия Добавить определяет право связывания текущей записи с другими записями на основе отношения N:1 или N:N.


Как это выглядит на практике.
А) Предположим, нам нужно разрешить Руководителю добавлять в Возможные сделки своих подчиненных записи Заказов. Мы знаем, что Возможная сделка связана с Заказами отношением 1:N. Следовательно в роли безопасности Руководителя для Возможной сделке необходимо установить уровень доступа Подразделение в привилегии Добавить К.

Б) Предположим, нам нужно разрешить Руководителю добавлять в Возможные сделки своих подчиненных записи Конкурентов. Видим, что сущность Возможная сделка связана с сущностью Конкурент отношением N:N. Следовательно в роли безопасности Руководителя для Возможной сделке необходимо установить уровень доступа Подразделение в привилегии Добавить.

Есть еще более простое правило определения, для какой привилегии (Добавить или Добавить К) необходимо устанавливать требуемый уровень доступа:

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

Пример: Любое Действие имеет поле В отношении, в котором указывается ссылка на Организацию или Контакт. Следовательно, чтобы разрешить добавлять в чужие Организации и Контакты свои или чужие Действия, необходимо настроить соответствующим образом уровень доступа в привилегии Добавить К для сущностей Организация и Контакт.

Продолжение следует. Дальше поговорим об исключениях в правилах.