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