В практике разработки на платформе 1С:Предприятие 8.3 часто возникает задача разграничения видимости данных между различными категориями сотрудников. Одной из классических задач является фильтрация справочника Пользователи, чтобы, например, продавцы видели в списках только своих коллег с аналогичной ролью, в то время как администраторы имели доступ ко всем записям. Рассмотрим детально, как реализовать подобное ограничение с помощью механизма RLS (Row Level Security) и почему прямая проверка ролей в этом случае не сработает.
Начнем с того, почему начинающие разработчики часто заходят в тупик. Попытка написать в конструкторе ограничений доступа условие вида ГДЕ РольДоступна("Продавец") приведет к ошибке. Разберем причину: запросы RLS транслируются платформой непосредственно в SQL-запросы к системе управления базами данных (СУБД). На уровне СУБД (будь то MS SQL Server или PostgreSQL) понятия «роль 1С» в том виде, в котором мы к ней привыкли в конфигураторе, просто не существует. Таблицы ролей и прав доступа 1С имеют сложную структуру метаданных, которую невозможно эффективно «подклеить» к каждому запросу на выборку данных.
Поэтому в языке запросов ограничений доступа невозможно использовать программные функции глобального контекста. Нам необходим «посредник», который передаст информацию о правах текущего пользователя из сессии 1С в SQL-контекст. Таким посредником выступают параметры сеанса.
Этот метод считается наиболее производительным и корректным с точки зрения архитектуры платформы. Проанализируем процесс реализации по шагам.
Шаг 1. Создание параметра сеанса
В дереве метаданных конфигурации перейдем в ветку Общие -> Параметры сеанса. Создадим новый параметр, например, с именем ЭтоПродавец. Установим для него тип Булево. Если необходимо хранить список доступных групп, можно использовать тип ФиксированныйМассив.
Шаг 2. Инициализация параметра в модуле сеанса
Параметры сеанса должны инициализироваться при старте системы. Перейдем в Модуль сеанса и найдем процедуру УстановкаПараметровСеанса. Пропишем в ней логику определения роли текущего пользователя:
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
// Проверяем наличие роли и устанавливаем значение параметра
Если РольДоступна("Продавец") Тогда
ПараметрыСеанса.ЭтоПродавец = Истина;
Иначе
ПараметрыСеанса.ЭтоПродавец = Ложь;
КонецЕсли;
КонецПроцедуры
Шаг 3. Настройка RLS в роли
Теперь перейдем к настройке роли (например, роли Продавец). Выберем справочник Пользователи, перейдем на вкладку «Ограничения доступа» и для права «Чтение» добавим запрос. Текст запроса будет выглядеть следующим образом:
ГДЕ &ЭтоПродавец = ЛОЖЬ
ИЛИ (Ссылка.ЯвляетсяПродавцом = ИСТИНА)
В данном примере мы предполагаем, что в самом справочнике Пользователи есть реквизит ЯвляетсяПродавцом. Если же нам нужно, чтобы администраторы видели всех, а продавцы — только продавцов, логика будет строиться от обратного. Рассмотрим ситуацию, когда ограничение накладывается на саму роль продавца:
ГДЕ Ссылка.РеквизитРоль = "Продавец"
Важный момент: использование знака & перед именем параметра сеанса в запросе RLS обязательно — так платформа понимает, что нужно подставить заранее вычисленное значение из памяти сервера.
Если в системе много ролей и сложная структура подчиненности, создание десятков параметров сеанса может быть избыточным. Проанализируем вариант с использованием стандартного справочника ГруппыПользователей.
В этом случае в запросе RLS мы можем обращаться к составу групп. Рассмотрим пример запроса:
ГДЕ Ссылка В
(ВЫБРАТЬ Состав.Пользователь
ИЗ Справочник.ГруппыПользователей.Состав КАК Состав
ГДЕ Состав.Ссылка.Наименование = "Продавцы")
Однако помните: этот метод работает медленнее, чем параметры сеанса. При каждом обращении к справочнику Пользователи СУБД будет вынуждена выполнять соединение (JOIN) с таблицей состава групп. При большом количестве записей это приведет к заметному снижению производительности интерфейса.
При внедрении RLS крайне важно учитывать нагрузку на сервер базы данных. Рассмотрим рекомендации по оптимизации:
ГДЕ запроса RLS, должны быть проиндексированы. Если вы фильтруете пользователей по реквизиту Подразделение или СпецПризнак, убедитесь, что в свойствах реквизита установлено значение Индексировать. Без индекса SQL-сервер будет выполнять полное сканирование таблицы (Full Scan), что «повесит» систему при росте базы.УстановитьПривилегированныйРежим(Истина). Это полезно для служебных алгоритмов, которым нужен доступ ко всем данным, независимо от прав текущего пользователя.Если ваша конфигурация построена на базе БСП (что актуально для большинства современных решений, таких как ERP, УТ 11, ЗУП 3), то задачу лучше решать через механизмы подсистемы «Управление доступом».
В БСП уже реализованы шаблоны ограничений, такие как #ПоЗначениям. Вместо написания «сырого» SQL-запроса, вы настраиваете Профили групп доступа и Виды доступа. Система автоматически заполняет служебные регистры сведений (например, КлючиДоступаКОбъектам), и RLS работает через обращение к этим предрассчитанным данным. Это значительно ускоряет работу системы в многопользовательском режиме.
Выясним причину выбора в пользу БСП: это позволяет избежать внесения изменений в структуру ролей при каждом изменении бизнес-логики. Вам достаточно просто добавить пользователя в нужную Группу доступа в пользовательском режиме, не заходя в Конфигуратор.
Подводя итог, можно сказать, что для решения задачи фильтрации справочника по ролям в 1С наиболее эффективным является сочетание параметров сеанса и четко выверенных индексированных реквизитов. Мы проанализировали основные подходы и выяснили, что прямая проверка ролей в запросе невозможна, а использование групп пользователей требует внимательного отношения к производительности. При разработке в современных типовых решениях всегда отдавайте приоритет механизмам Библиотеки стандартных подсистем, так как они обеспечивают наиболее гибкую и стабильную работу механизмов безопасности.