Как настроить ограничение доступа на уровне записей (RLS) для документа в 1С?

Механизм RLS (Row Level Security) в платформе 1С позволяет ограничивать права пользователей на чтение, изменение или добавление отдельных записей в таблицах СУБД на основе определенных условий. Разберем по шагам, как настроить ограничение доступа к документам, где находятся нужные настройки в конфигураторе и на что следует обратить внимание для обеспечения корректной и быстрой работы системы.

Где найти роли и ограничения доступа в дереве метаданных

Рассмотрим, где именно в конфигураторе 1С задаются ограничения RLS. Все правила доступа привязаны к объекту метаданных Роли.

1. Откроем дерево конфигурации.
2. Развернем ветку Общие и найдем узел Роли.
3. Выберем нужную роль или создадим новую.
4. В окне редактирования роли перейдем на вкладку Права и выберем интересующий нас документ (например, ЗаказПокупателя).
5. В нижней части окна зададим ограничение для конкретного права (например, Чтение или Изменение).

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

Настройка текста RLS: базовый пример и работа с конструктором

Посмотрим на базовое условие ограничения. Если требуется показывать пользователю только те заказы, где он указан в качестве ответственного лица, на языке запросов 1С условие RLS выглядит следующим образом:

ГДЕ Заказ.Ответственный = &ТекущийПользователь

Для создания такого текста проще всего использовать встроенный **Конструктор ограничения доступа**. Он позволяет выстроить логическое условие без ошибок в синтаксисе.

Подводные камни: обработка пустых значений (NULL) и параметров сеанса

Проанализируем типовые ошибки, которые часто возникают при самостоятельной настройке RLS.

1. Обработка незаполненных реквизитов (NULL)
Если в документе реквизит Ответственный не заполнен, прямое сравнение вернет NULL (Ложь). В результате документ будет полностью скрыт от пользователя. Чтобы этого избежать, обязательно используем функцию ЕСТЬNULL:

ГДЕ ЕСТЬNULL(Заказ.Ответственный, ЗНАЧЕНИЕ(Справочник.Пользователи.ПустаяСсылка)) = &ТекущийПользователь

2. Инициализация параметров сеанса
Использование сеансового параметра &ТекущийПользователь требует его обязательной инициализации в модуле сеанса. Если параметр не заполнен при старте системы, любое обращение к объекту вызовет ошибку прав доступа. Проверим код в модуле сеанса:

Процедура УстановкаПараметровСеанса(ИменаПараметров)
    Если ИменаПараметров = Неопределено Или ИменаПараметров.Найти("ТекущийПользователь") <> Неопределено Тогда
        ПараметрыСеанса.ТекущийПользователь = ПользователиИнформационнойБазы.ТекущийПользователь();
    КонецЕсли;
КонецПроцедуры

Особенности работы RLS и производительность СУБД

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

1. Индексация реквизитов: Поле документа, по которому строится ограничение (например, Ответственный), должно обязательно иметь свойство «Индексировать» в метаданных. В противном случае СУБД будет выполнять сканирование всей таблицы при каждом запросе.
2. Комбинирование нескольких ролей: Если пользователю назначено несколько ролей с ограничениями RLS, платформа объединяет их условия по правилу ИЛИ. Если хотя бы одна роль дает неограниченное право на чтение объекта, RLS из других ролей не сработает.
3. Подсистема «Управление доступом» БСП: В современных типовых конфигурациях рекомендуется использовать штатный механизм БСП. Ручные правки RLS в ролях могут входить в конфликт с БСП. Переопределение прав в БСП выполняется через процедуру ПриЗаполненииОграниченияДоступа в модуле менеджера объекта.

Альтернативные варианты ограничения доступа

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

• Фиксированный отбор в динамическом списке: Настраивается программно при открытии формы списка через Список.КомпоновщикНастроек.ФиксированныеНастройки.Отбор. Это исключает нагрузку на СУБД, отсекая лишние записи на уровне интерфейса.
• Проверки в событиях формы и модуля: Для запрета просмотра чужих документов используется проверка в событии ПриОткрытии формы документа, а для блокировки записи — в событии ПередЗаписью модуля объекта.
• Привилегированный режим: В служебных алгоритмах и фоновых заданиях, где RLS мешает проведению или расчету итогов, используем вызов УстановитьПривилегированныйРежим(Истина).