В современных конфигурациях, построенных на базе Библиотеки стандартных подсистем (БСП), таких как 1С:ERP Управление предприятием, Комплексная автоматизация или Управление торговлей, программисты часто сталкиваются с парадоксальной ситуацией. Несмотря на то что основная функциональная опция ОграничиватьДоступНаУровнеЗаписей выключена, система продолжает применять ограничения, выдавать ошибки прав доступа или замедлять работу из-за расчета ключей доступа. Разберем подробно, почему это происходит, как работают внутренние механизмы БСП и что нужно сделать для полного отключения RLS.
Первым делом проанализируем структуру констант, отвечающих за безопасность. В БСП реализовано два принципиально разных механизма ограничения доступа на уровне записей:
ОграничиватьДоступНаУровнеЗаписей. Это классический механизм, который существовал в платформе «из коробки» долгие годы.ОграничиватьДоступНаУровнеЗаписейУниверсально. Он появился в более новых версиях БСП для оптимизации запросов и снижения нагрузки на СУБД.Многие специалисты ошибочно полагают, что «Универсальный режим» — это лишь расширение или надстройка над основным. Однако на практике эти константы технически независимы. Если вы отключаете основную опцию через интерфейс, система может оставить включенным «производительный режим». В этом случае платформа продолжает обрабатывать шаблоны RLS, ориентируясь на состояние именно второй константы.
Чтобы понять, почему возникают синтаксические ошибки вроде Не удалось определить вариант ограничения доступа в параметрах сеанса для шаблона ДляОбъекта, посмотрим на то, как написаны стандартные шаблоны ограничений в БСП. Большинство из них активно используют инструкции препроцессора.
Рассмотрим пример типичного кода шаблона:
#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
// Здесь идет логика производительного режима (проверка через ключи доступа)
#ДляОбъекта("Документ.ОплатаМСФО")
#Иначе
// Здесь идет логика классического RLS
ГДЕ ...
#КонецЕсли
Когда вы выключаете основную константу, но оставляете ОграничиватьДоступНаУровнеЗаписейУниверсально в значении Истина, платформа при выполнении любого запроса заходит в ветку «Тогда». Если при этом объект (например, новый документ или справочник) не был должным образом зарегистрирован в подсистеме управления доступом, параметры сеанса, необходимые для работы шаблона, не инициализируются. Это и приводит к ошибкам компиляции запроса прямо на этапе инициализации платформой.
Проанализируем еще один важный аспект: нагрузку на систему. Даже если права формально не ограничиваются, но «производительный режим» активен, система продолжает выполнять регламентные задания по обновлению ключей доступа. Процессы будут обращаться к регистрам КлючиДоступаКОбъектам, КлючиДоступаКРегистрам и пытаться рассчитать права для всех метаданных.
Это происходит потому, что логика БСП настроена на поддержание актуальности данных: если механизм включен, ключи должны быть рассчитаны «на всякий случай», чтобы при фактическом включении ограничений система была готова к работе без длительных задержек на расчет. Таким образом, неполное отключение RLS (только одной константой) не освобождает ресурсы сервера, а иногда даже вводит систему в состояние конфликта настроек.
Если ваша задача — полностью избавиться от влияния RLS в базе данных, выполним следующие шаги:
Перейдите в раздел НСИ и администрирование — Настройка пользователей и прав — Группы доступа. Убедитесь, что выключены оба флага:
Важно: Всегда используйте интерфейсные формы для изменения этих настроек, так как при записи константы через интерфейс срабатывают обработчики событий, которые могут очищать кэши, обновлять параметры сеанса или изменять зависимые опции.
Иногда программные ошибки или расширения могут препятствовать корректному изменению констант. Проверим реальное состояние значений в базе данных с помощью небольшого фрагмента кода:
Сообщить("Стандартный RLS: " + Константы.ОграничиватьДоступНаУровнеЗаписей.Получить());
Сообщить("Универсальный RLS: " + Константы.ОграничиватьДоступНаУровнеЗаписейУниверсально.Получить());
Если вы видите, что универсальный режим включен (Истина), а стандартный выключен — это именно та ситуация, которая вызывает ошибки в шаблонах запросов. Принудительно установите значение в Ложь и перезапустите сеанс.
Если же RLS вам необходим, но вы получаете синтаксическую ошибку на конкретном объекте (как в случае с Документ.ОплатаМСФО), необходимо правильно «прописать» объект в подсистеме. Выясним причину ошибки: объект отсутствует в определяемых типах подсистемы.
Рассмотрим, какие метаданные нужно проверить:
ПриЗаполненииСписковСПодавлениемОграниченийДоступа.После добавления объекта в подсистему необходимо обновить параметры сеанса. Самый простой способ сделать это в режиме 1С:Предприятие — воспользоваться обработкой «Обновление вспомогательных данных» из состава БСП или просто перезайти в систему под пользователем с полными правами, чтобы сработали процедуры инициализации.
Подводя итог нашему анализу, зафиксируем ключевые выводы. Механизм RLS в БСП — это сложная система, где параметры сеанса играют критическую роль в компиляции запросов СУБД. Для корректной работы или полного отключения системы безопасности необходимо следить за синхронностью состояний констант.
Помните, что переключение режима в «Стандартный» при выключенном основном RLS фактически делает шаблоны ИСТИНА, так как препроцессор начинает использовать ветку #Иначе, где обычно нет сложных проверок. Это «лечит» синтаксические ошибки, но правильным архитектурным решением будет полное отключение обеих функциональных опций, если ограничения в базе не используются.