Разработка ролей в библиотеках

Методическая рекомендация (полезный совет)

1. При проектировании ролей в библиотеках рекомендуется придерживаться общего подхода к определению границ функциональности библиотеки:

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

2. В большинстве случаев, библиотека должна предоставлять готовый набор ролей для работы со своими данными (с объектами метаданных, содержащих данные: справочники, регистры и т.п.).

Например, вместе с универсальной подсистемой анкетирования в библиотеку входят роли для добавления и изменения шаблонов, опросов, ответов на вопросы анкет, просмотра ответов на вопросы и для администрирования (настройки) подсистемы анкетирования.

Исключение из этого правила составляют случаи, когда

• библиотечный объект не является «самостоятельным», а всегда подчинен какому-либо объекту-владельцу конфигурации. Например: библиотечные присоединенные файлы к объектам конфигурации ( номенклатуре , проектам и т.п.) не имеет собственных ролей, т.к. доступ к файлам задается в ролях для работы с номенклатурой, проектами и т.п.
• библиотечный объект не является полностью законченным объектом, готовым для использования «как есть», а предполагает существенное переопределение в прикладных решениях. Например, библиотечные справочники Организации, Физические лица и т.п. содержат минимальную базовую реализацию, общую для всех прикладных решений, и не предоставляют «полноценные» роли для работы с ними.
• библиотека не содержит данных, а только алгоритмы для работы с ними.

3. При этом в ролях могут быть определены не только права к библиотечным объектам, но и логика ограничений доступа к ним на уровне записей (RLS – Row-Level Security).

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

Исключение из этого правила составляют случаи, когда

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

4. При использовании в библиотеке правил поставки для всех библиотечных ролей следует задавать правило поставки «Изменения разрешены». Это требование обусловлено технологическими особенностями платформы 1С:Предприятие: при добавлении/удалении метаданных в конфигурации происходит неявно изменение ролей.

См. также

• Стандартные роли
• Переопределяемые и поставляемые объекты библиотеки