Как настроить RLS на чтение через парсинг XML и производительный RLS в 1С

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

Парсинг ролей через выгрузку в XML и CI/CD

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

Рассмотрим по шагам, как это можно реализовать на практике:

1. Выгружаем конфигурацию в файлы (формат XML) или используем формат выгрузки 1C:EDT, где роли изначально хранятся в отдельных текстовых файлах (как правило, с расширением прав).
2. Находим нужные объекты метаданных и их права. В выгруженных файлах RLS физически располагается внутри тегов restrictionByCondition.
3. Используя внешние скрипты, парсим эти файлы на этапе автоматической сборки релизов.
4. Программно удаляем или заменяем типовые тяжелые шаблоны на чтение на свои собственные оптимизированные корпоративные шаблоны.

Посмотрим на пример того, как выглядит типовой RLS в выгруженном файле конфигурации для регистра сведений:

<object>
    <name>InformationRegister.МестонахождениеОСБухгалтерскийУчет</name>
    <right>
        <name>Read</name>
        <value>true</value>
        <restrictionByCondition>
            <condition>#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляРегистра("ИдентификаторыОбъектовМетаданных.РегистрСведенийМестонахождениеОСБухгалтерскийУчет", "Организация", "", "", "", "")
#Иначе
// ОсновноеУсловиеЧтение
// Можно читать если есть доступ к (по или)
#ПоЗначениям("РегистрСведений.МестонахождениеОСБухгалтерскийУчет", "Чтение", "",
"Организации", "Организация",
"","",
"",""
)
#КонецЕсли</condition>
        </restrictionByCondition>
    </right>
</object>

С помощью скриптового парсинга мы можем легко подменить содержимое тега condition нужным нам запросом перед сборкой файла конфигурации. Это позволяет легко обновлять систему: типовые роли обновляются штатными средствами, а наши изменения "накатываются" скриптом автоматически без ручного вмешательства.

Использование производительного RLS от БСП

Если вариант с парсингом и внешними скриптами кажется избыточным, обратим внимание на механизм под названием "Производительный RLS", который встроен в современные версии Библиотеки стандартных подсистем.

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

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

Посмотрим на пример кода, который необходимо разместить в модуле менеджера для программного определения производительного RLS:

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

Проанализируем суть этой процедуры. Эти "сырые" тексты используются системой не как прямой запрос к СУБД, а исключительно как правила для заполнения регистров доступных данных. В самих же ролях конфигурации при этом прописывается один короткий шаблон, который делает простую проверку: есть ли ключ читаемого объекта в разрешенном регистре. Это колоссально снижает нагрузку на базу данных и ускоряет вывод списков.

Альтернативные методы: собственные регистры и подписки на события

Иногда ни типовой производительный RLS, ни скриптовый парсинг не подходят. Рассмотрим альтернативные пути обхода проблемы.

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

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

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