Настройка ролей безопасности: привилегии Добавить и Добавить К
Запись от Fighter размещена 08.02.2012 в 16:31
Первое беглое прочтение юзергайда в разрезе Ролей безопасности не вызвало у меня никакой настороженности, а добавило только положительных эмоций от ощущения законченности и продуманности механизмы защиты данных и разграничения доступа.
Но нюансы кроются в деталях. Когда основная кастомизация CRM для организации была выполнена, пришло время тонкой настройки привилегий пользователей. И здесь оказалось, что с ролями безопасности не все так просто и не стоит верить всему тому, что написано в справке.
Попробуем разобраться.
Общее правило звучит так:
Определение роли безопасности заключается в назначении привилегий на каждом уровне доступа для каждой сущности.
Пример:
Открываем Роль безопасности Продавец, находим сущность Интерес, переходим в столбец с привилегией Создание, определяем уровень доступа Пользователь. Переходим в столбец Чтение, определяем уровень доступа Подразделение. Переходим в столбец Запись, определяем уровень доступа Пользователь. Переходим в столбец Удаление, определяем уровень доступа Нет…
Все просто и понятно… пока мы не дошли до привилегий Добавление и Добавление К.
Официальный CRM дает следующее определение этих привилегий:
Добавление — привилегия, необходимая для связывания записи с текущей записью. Например, имея права на добавление для возможной сделки, пользователь может добавлять примечания к возможной сделке. То, к каким записям можно добавлять данные, зависит от уровня доступа и прав, определенных в роли безопасности.
Добавление К — привилегия, необходимая для связывания текущей записи с другой записью. Например, чтобы добавить примечание к возможной сделке, пользователь должен обладать разрешениями "Добавление к" для примечания. То, к каким записям можно добавлять данные, зависит от уровня доступа и разрешений, определенных в роли безопасности.
Проверим это на практике.
Рассмотрим пример разграничения прав по доступу к примечаниям Возможной сделки для продавца и его руководителя.
Мы хотим реализовать следующую политику безопасности: Продавец может добавлять только свои Примечания только в свою Возможную сделку. Руководитель может добавлять свои Примечания в Возможные сделки своих подчиненных.
Проверяем…Все работает. Отлично!
А теперь давайте поэкспериментируем: установите в Возможной сделке в роли безопасности Руководителя уровень доступа для привилегии Добавление К = Пользователь.
Теперь попробуйте добавить под Руководителем Примечание к Возможной сделке подчиненного. Получите сообщение об ошибке: недостаточно прав.
И проблема здесь лежит в правильном толковании сути привилегий Добавление и Добавление К.
Правильное определение, на мой взгляд, должно звучать следующим образом:
Привилегия Добавить К определяет право на добавление в текущую запись других записей, связанных с текущей записью отношением 1:N (где 1 – это текущая запись).
Привилегия Добавить определяет право на добавление в текущую запись других записей, связанных с текущей записью отношением N:1 (где 1 – это добавляемая запись).
Или более точно:
Привилегия Добавить К определяет право связывания текущей записи с другими записями на основе отношения 1:N.
Привилегия Добавить определяет право связывания текущей записи с другими записями на основе отношения N:1 или N:N.
Как это выглядит на практике.
А) Предположим, нам нужно разрешить Руководителю добавлять в Возможные сделки своих подчиненных записи Заказов. Мы знаем, что Возможная сделка связана с Заказами отношением 1:N. Следовательно в роли безопасности Руководителя для Возможной сделке необходимо установить уровень доступа Подразделение в привилегии Добавить К.
Б) Предположим, нам нужно разрешить Руководителю добавлять в Возможные сделки своих подчиненных записи Конкурентов. Видим, что сущность Возможная сделка связана с сущностью Конкурент отношением N:N. Следовательно в роли безопасности Руководителя для Возможной сделке необходимо установить уровень доступа Подразделение в привилегии Добавить.
Есть еще более простое правило определения, для какой привилегии (Добавить или Добавить К) необходимо устанавливать требуемый уровень доступа:
Если текущая запись появляется в связываемых записях в поле В отношении, то надо использовать привилегию Добавить К.
Если в текущей записи для просмотра связанных записей используется грид (как правило, на отдельной вкладке), то надо использовать привилегию Добавить.
Пример: Любое Действие имеет поле В отношении, в котором указывается ссылка на Организацию или Контакт. Следовательно, чтобы разрешить добавлять в чужие Организации и Контакты свои или чужие Действия, необходимо настроить соответствующим образом уровень доступа в привилегии Добавить К для сущностей Организация и Контакт.
Продолжение следует. Дальше поговорим об исключениях в правилах.
Но нюансы кроются в деталях. Когда основная кастомизация CRM для организации была выполнена, пришло время тонкой настройки привилегий пользователей. И здесь оказалось, что с ролями безопасности не все так просто и не стоит верить всему тому, что написано в справке.
Попробуем разобраться.
- Роль безопасности = (Привилегии на уровне записи | Привилегии на уровне задач) + Уровень доступа.
- Привилегии на уровне записи = { Создание, Чтение, Редактирование, Удаление, Добавление, Добавление К, Назначение, Общий доступ }
- Привилегии на уровне задач = { Отдельные специальные задачи }
- Уровень доступа = { Нет, Пользователь, Подразделение, Головное + дочерние подразделения, Организация }
Общее правило звучит так:
Определение роли безопасности заключается в назначении привилегий на каждом уровне доступа для каждой сущности.
Пример:
Открываем Роль безопасности Продавец, находим сущность Интерес, переходим в столбец с привилегией Создание, определяем уровень доступа Пользователь. Переходим в столбец Чтение, определяем уровень доступа Подразделение. Переходим в столбец Запись, определяем уровень доступа Пользователь. Переходим в столбец Удаление, определяем уровень доступа Нет…
Все просто и понятно… пока мы не дошли до привилегий Добавление и Добавление К.
Официальный CRM дает следующее определение этих привилегий:
Добавление — привилегия, необходимая для связывания записи с текущей записью. Например, имея права на добавление для возможной сделки, пользователь может добавлять примечания к возможной сделке. То, к каким записям можно добавлять данные, зависит от уровня доступа и прав, определенных в роли безопасности.
Добавление К — привилегия, необходимая для связывания текущей записи с другой записью. Например, чтобы добавить примечание к возможной сделке, пользователь должен обладать разрешениями "Добавление к" для примечания. То, к каким записям можно добавлять данные, зависит от уровня доступа и разрешений, определенных в роли безопасности.
Проверим это на практике.
Рассмотрим пример разграничения прав по доступу к примечаниям Возможной сделки для продавца и его руководителя.
Мы хотим реализовать следующую политику безопасности: Продавец может добавлять только свои Примечания только в свою Возможную сделку. Руководитель может добавлять свои Примечания в Возможные сделки своих подчиненных.
- Для чистоты эксперимента устанавливаем в сущностях Возможная сделка и Примечание для привилегий Создать и Запись уровень доступа Подразделение для Продавца и его Руководителя.
- Устанавливаем в сущности Возможная сделка: у Продавца привилегия Добавление = Пользователь; у Руководителя привилегия Добавление = Подразделение.
- Устанавливаем в сущности Примечание: у Продавца привилегия Добавление К = Пользователь; у Руководителя привилегия Добавление К = Пользователь.
Проверяем…Все работает. Отлично!
А теперь давайте поэкспериментируем: установите в Возможной сделке в роли безопасности Руководителя уровень доступа для привилегии Добавление К = Пользователь.
Теперь попробуйте добавить под Руководителем Примечание к Возможной сделке подчиненного. Получите сообщение об ошибке: недостаточно прав.
И проблема здесь лежит в правильном толковании сути привилегий Добавление и Добавление К.
Правильное определение, на мой взгляд, должно звучать следующим образом:
Привилегия Добавить К определяет право на добавление в текущую запись других записей, связанных с текущей записью отношением 1:N (где 1 – это текущая запись).
Привилегия Добавить определяет право на добавление в текущую запись других записей, связанных с текущей записью отношением N:1 (где 1 – это добавляемая запись).
Или более точно:
Привилегия Добавить К определяет право связывания текущей записи с другими записями на основе отношения 1:N.
Привилегия Добавить определяет право связывания текущей записи с другими записями на основе отношения N:1 или N:N.
Как это выглядит на практике.
А) Предположим, нам нужно разрешить Руководителю добавлять в Возможные сделки своих подчиненных записи Заказов. Мы знаем, что Возможная сделка связана с Заказами отношением 1:N. Следовательно в роли безопасности Руководителя для Возможной сделке необходимо установить уровень доступа Подразделение в привилегии Добавить К.
Б) Предположим, нам нужно разрешить Руководителю добавлять в Возможные сделки своих подчиненных записи Конкурентов. Видим, что сущность Возможная сделка связана с сущностью Конкурент отношением N:N. Следовательно в роли безопасности Руководителя для Возможной сделке необходимо установить уровень доступа Подразделение в привилегии Добавить.
Есть еще более простое правило определения, для какой привилегии (Добавить или Добавить К) необходимо устанавливать требуемый уровень доступа:
Если текущая запись появляется в связываемых записях в поле В отношении, то надо использовать привилегию Добавить К.
Если в текущей записи для просмотра связанных записей используется грид (как правило, на отдельной вкладке), то надо использовать привилегию Добавить.
Пример: Любое Действие имеет поле В отношении, в котором указывается ссылка на Организацию или Контакт. Следовательно, чтобы разрешить добавлять в чужие Организации и Контакты свои или чужие Действия, необходимо настроить соответствующим образом уровень доступа в привилегии Добавить К для сущностей Организация и Контакт.
Продолжение следует. Дальше поговорим об исключениях в правилах.
Всего комментариев 0
