Можно ли использовать функцию РольДоступна() в ограничениях доступа (RLS) в 1С?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Почему РольДоступна() нельзя использовать в RLS?

Первое, что необходимо уяснить: система RLS — это механизм фильтрации данных на уровне СУБД или на этапе формирования выборки данных. Функция РольДоступна() является прикладной функцией, которая работает в контексте исполнения кода 1С. Включение её в текст ограничения доступа не поддерживается платформой по ряду критических причин:

  1. Производительность: Механизм RLS накладывается на каждое обращение к данным. Если бы система выполняла проверку ролей для каждой строки при выполнении сложного запроса, это привело бы к катастрофическому падению скорости работы всей базы данных.
  2. Архитектурная логика: RLS по своей сути работает по принципу объединения условий всех ролей, назначенных пользователю, через оператор ИЛИ. Внедрение проверки других ролей внутри кода одной конкретной роли создает логические конфликты и усложняет аудит безопасности.
  3. Принцип изоляции: RLS должен зависеть от данных, которые можно однозначно интерпретировать для любой строки таблицы (например, значение поля Организация или Склад). Состояние сеанса пользователя — это внешняя переменная, а не атрибут записи.

Правильный подход: использование параметров сеанса

Для того чтобы учесть наличие у пользователя определенной роли при расчете RLS, необходимо использовать Параметры сеанса. Это единственный архитектурно верный способ передачи информации о контексте прав в систему ограничений.

Реализация этого решения проходит в несколько шагов:

  1. Создание параметра сеанса: Добавьте в конфигурацию параметр сеанса, например, ЭтоМенеджерПоПродажам (тип Булево).
  2. Установка параметра: В модуле сеанса, в процедуре УстановкаПараметровСеанса, выполните инициализацию этого параметра.

Разберем пример кода для модуля сеанса:


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

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


#Если &ЭтоМенеджерПоПродажам Тогда
    Истина
#Иначе
    ПолеОрганизация = &ТекущаяОрганизация
#КонецЕсли

Таким образом, проверка прав выполняется ровно один раз — в момент входа пользователя в систему, что сохраняет высокую скорость работы механизмов доступа.

Альтернатива: использование регистров сведений

Если ваша задача сложнее, чем простая проверка роли (например, нужно разрешить доступ только к конкретным складам или проектам), не пытайтесь перегружать роли логикой. Используйте для этих целей регистры сведений.

Рассмотрим преимущества этого подхода:

Для реализации этого метода:

  1. Создайте регистр сведений, хранящий связи «Пользователь» -> «Объект доступа».
  2. В шаблоне RLS укажите условие соединения, при котором объект будет доступен, если он присутствует в записях данного регистра для текущего пользователя.

Этот метод считается «золотым стандартом» для разработки сложных систем с динамическим ограничением доступа.

Подведем итоги

Использование РольДоступна() в RLS — это «антипаттерн», который приведет к ошибкам и проблемам с быстродействием. Вместо этого:

Соблюдая эти правила, вы обеспечите надежную, защищенную и производительную работу вашей системы 1С.

← На главную