Переход на производительный (упрощенный) режим RLS в 1С:Предприятие 8.3 — это важный шаг для оптимизации систем с большим количеством данных и пользователей. Однако при наличии доработанных ролей и кастомных шаблонов ограничений этот процесс вызывает множество вопросов. Рассмотрим подробно, как перенести старую логику ограничений в новый формат, как работать с модулем менеджера объекта и на что обратить внимание при написании запросов для ключей доступа.
Разберем, чем принципиально отличается новый подход. В классическом RLS проверка прав происходит динамически при каждом обращении к базе данных — система «на лету» модифицирует каждый SQL-запрос, добавляя в него условия ГДЕ. В производительном режиме проверка прав опирается на предварительно рассчитанные данные, которые хранятся в специальных таблицах — ключах доступа. Это позволяет значительно снизить нагрузку на СУБД, но требует от разработчика иного подхода к описанию ограничений.
Проанализируем основные правила работы в этом режиме:
Сотрудники на старом движке RLS, а другую перевести на производительный режим. Если объект переведен на ключи доступа, вся логика ограничений для него теперь описывается в модуле менеджера.&Вместо или &После для процедуры ПриЗаполненииОграниченияДоступа.Рассмотрим ситуацию, когда в конфигурации 1С:ЗУП 3 необходимо ограничить доступ к справочнику Сотрудники, используя не только типовые разрезы (Организации), но и свои собственные (например, по регистру или дополнительному реквизиту). В производительном режиме это делается через метод ПриЗаполненииОграниченияДоступа в модуле менеджера объекта.
Посмотрим на пример кода, который позволяет объединить проверку по организации из регистра сведений и проверку по физическому лицу:
&Вместо("ПриЗаполненииОграниченияДоступа")
Процедура преф_ПриЗаполненииОграниченияДоступа(Ограничение)
Ограничение.Текст =
"ПрисоединитьДополнительныеТаблицы
|ЭтотСписок КАК Т
|ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ОрганизацииВКоторыхРаботалиСотрудники КАК Т2
| ПО Т2.Сотрудник = Т.Ссылка
|;
|РазрешитьЧтениеИзменение
|ГДЕ
| ЗначениеРазрешено(Т2.Организация, null как Истина)
| И ЗначениеРазрешено(Т.ФизическоеЛицо)
| И ЗначениеРазрешено(Т.преф_Регион, ПустаяСсылка КАК Истина)";
КонецПроцедуры
Разберем по шагам, что происходит в этом коде:
ЛЕВОЕ СОЕДИНЕНИЕ позволяет корректно обрабатывать ситуации, когда записей в регистре еще нет (например, сотрудник создан, но не принят на работу).Роль. Если у пользователя роль «Только чтение», этот шаблон не даст ему права на изменение.null как Истина позволяет разрешить доступ, если поле не заполнено (актуально для новых записей).Выясним причину, по которой авторы часто беспокоятся о сотрудниках «до приема на работу». В ЗУП 3 сотрудник может быть создан в справочнике, но еще не иметь движений по регистрам. Если в RLS прописано жесткое условие через ВНУТРЕННЕЕ СОЕДИНЕНИЕ, такой сотрудник исчезнет из видимости. При использовании производительного режима и ЛЕВОГО СОЕДИНЕНИЯ с проверкой на NULL, мы обеспечиваем видимость таких объектов, пока им не будет присвоена конкретная аналитика доступа.
Просто написать код в модуле менеджера недостаточно. Выясним, какие дополнительные действия необходимо предпринять:
Регионы), необходимо убедиться, что этот тип добавлен в определяемый тип ЗначениеДоступа. Без этого система не сможет создать ключи доступа для этого типа данных.Сотрудники включен в список объектов, использующих производительный режим. Это настраивается в процедуре ПриЗаполненииСпискаОбъектовСПострочнымОграничением (в зависимости от версии БСП название может незначительно отличаться).Проанализируем ситуацию с появлением странных символов в коде, таких как <B>. Как было отмечено в обсуждении на форуме, это часто является результатом копирования кода из нейросетей или некорректного форматирования. В языке запросов 1С и языке RLS такие теги недопустимы и приведут к ошибке синтаксиса при компиляции запроса. Всегда внимательно проверяйте текст в переменной Ограничение.Текст.
Также важно помнить про производительность самих запросов в модуле менеджера. Хотя режим и называется производительным, тяжелые соединения с множеством таблиц внутри ПриЗаполненииОграниченияДоступа могут замедлить процесс расчета ключей, что приведет к зависанию регламентных заданий при массовом изменении данных. Для выборочной актуализации данных вместо запуска фонового пересчета всей базы можно применить обработку для точечного пересчета прав доступа пользователей.
Подводя итог, можно сказать: переводить доработанные конфигурации на производительный RLS можно и нужно, но это требует полной инвентаризации всех кастомных ролей и их переписывания на новый синтаксис внутри модулей менеджеров соответствующих объектов. В качестве альтернативы без ручной модификации кода в модулях можно использовать расширение для настройки прав доступа к объектам с гибкими отборами.