← На главную

При разработке собственных объектов в типовых конфигурациях (таких как 1С:Управление торговлей 11, ERP 2 или Комплексная автоматизация) разработчики часто сталкиваются с задачей включения нового документа в общую систему разграничения прав доступа на уровне записей (RLS). Попробуем разобраться, как правильно настроить ограничение доступа по организации и складу для нового документа и почему стандартная настройка ролей может приводить к частичному отображению данных.

Почему документы отображаются в списке с пустыми значениями

Проанализируем типичную ситуацию: создан новый документ (например, ПоступлениеОборудования) с реквизитами Организация, Склад и Ответственный. Разработчик включает RLS для справочника организаций, создает профиль и группу доступа, однако в динамическом списке документов пользователь все равно видит все строки, при этом в колонке организации отображается пустое поле или надпись <Объект не найден>.

Выясним причину такого поведения платформы. Если ограничение доступа настроено только на уровне справочника Организации, а на саму таблицу документа ограничение на право Чтение не наложено, платформа считывает список документов целиком. При попытке получить представление организации срабатывает RLS справочника, запрещающий чтение конкретного элемента, из-за чего значение реквизита скрывается, но сама строка документа остается в списке. Чтобы документ полностью исчез из динамического списка, условие ограничения должно применяться непосредственно к правам самого документа.

Пошаговый алгоритм настройки RLS в типовых конфигурациях на БСП

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

1. Регистрация документа в метаданных БСП. Откроем дерево метаданных конфигурации и добавим наш документ в следующие определяемые типы:
   • ВладелецЗначенийКлючейДоступа
   • ВладелецЗначенийКлючейДоступаДокумент
2. Регистрация объекта в общем модуле. Перейдем в общий модуль УправлениеДоступомПереопределяемый и найдем процедуру ПриЗаполненииСписковСОграничениемДоступа. Добавим строку с регистрацией нашего документа:
   Скопировать код

   
   Процедура ПриЗаполненииСписковСОграничениемДоступа(Списки) Экспорт
       
       // Регистрация нетипового документа в механизме RLS
       Списки.Вставить(Метаданные.Документы.ПоступлениеОборудования, Истина);
       
   КонецПроцедуры
   

3. Настройка модуля менеджера документа. Откроем модуль менеджера нашего документа Документ.ПоступлениеОборудования и разместим там экспортную процедуру описания ограничений:
   Скопировать код

   
   Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
   
       Ограничение.Текст =
       "РазрешитьЧтениеИзменение
       |ГДЕ
       |   ЗначениеРазрешено(Организация)
       |   И ЗначениеРазрешено(Склад)";
   
   КонецПроцедуры
   

   В этом коде макрокоманда ЗначениеРазрешено указывает подсистеме управления доступом контролировать реквизиты документа по соответствующим видам доступа.

4. Настройка ролей в конфигураторе. Создадим отдельную роль или скопируем шаблон ограничений из типовой роли (например, ЧтениеПоступленийТоваровУслуг). В правах роли для документа ПоступлениеОборудования укажем ограничение на право Чтение и Изменение с использованием типового шаблона БСП ПоЗначениям.
5. Создание профилей и групп доступа в режиме предприятия. Запустим программу в режиме «1С:Предприятие»:
   • Откроем справочник Профили групп доступа, создадим новый профиль и отметим созданную роль. На вкладке Ограничения доступа для вида доступа «Организации» установим вариант «Все разрешены, кроме исключений» или «Все запрещены, кроме разрешенных».
   • Создадим Группу доступа на основании данного профиля, укажем конкретных пользователей и выберем разрешенные для них организации.
6. Обновление регистров ключей доступа. После внесения изменений необходимо запустить регламентное задание обновления доступа или воспользоваться сервисной обработкой из БСП для пересчета прав, чтобы ключи доступа сформировались для всех существующих документов.

Особенности ограничения по складам и иерархическим справочникам

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

Выясним причину: RLS по умолчанию выполняет проверку на прямое равенство ссылки разрешенному значению. Если вид доступа не настроен на учет иерархии, платформа сравнивает родительскую группу из настроек прав с конкретным складом в документе, из-за чего совпадение не находится. Для корректной работы с группами складов необходимо, чтобы для соответствующего вида доступа в БСП было включено использование групп значений доступа и корректно заполнялся служебный регистр сведений ГруппыЗначенийДоступа.

Правила объединения групп и профилей доступа

Разберем логику комбинирования прав при назначении пользователю нескольких настроек:

1. Несколько групп доступа у одного пользователя (объединение по правилу «ИЛИ»). Если пользователю назначено две группы доступа (например, в одной разрешена «Организация А», а в другой — «Организация Б»), права суммируются. Пользователь получит доступ к документам обеих организаций. Назначения не перекрывают друг друга, а расширяют доступ.
2. Несколько видов доступа внутри одного профиля (объединение по правилу «И»). Если в рамках одного профиля ограничены и «Организации», и «Склады», документ откроется пользователю только в том случае, если одновременно разрешены и организация, и склад, указанные в документе.

Рекомендации по оптимизации производительности RLS

Ограничение на уровне записей создает дополнительную нагрузку на СУБД, так как модифицирует исходные запросы платформы. Чтобы избежать падения производительности динамических списков и отчетов, обратим внимание на следующие правила:

1. Все реквизиты, участвующие в RLS (в нашем случае Организация и Склад), должны иметь свойство Индексировать или Индексировать с доп. упорядочиванием.
2. Не следует использовать сложные запросы с соединениями внутри текста ограничений в ролях — предпочтительно использовать механизм ключей доступа БСП, где все тяжелые проверки рассчитываются заранее в фоновом режиме.