Как реализовать RLS для фильтрации номенклатуры по текущему пользователю?

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

Основные принципы работы RLS

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

Шаг 1: Создание параметра сеанса

Первым делом нам необходимо создать параметр сеанса ТекущийПользователь. Тип данных для этого параметра должен соответствовать ссылочному типу вашего справочника Пользователи. Без этого параметра платформа не сможет «узнать», кто именно запрашивает данные в данный момент.

Шаг 2: Заполнение параметра сеанса при входе

Чтобы параметр ТекущийПользователь был заполнен данными, мы должны прописать логику его инициализации в модуле сеанса. Это происходит при запуске системы, когда платформа выполняет процедуру УстановкаПараметровСеанса. Рассмотрим пример реализации:

Процедура УстановкаПараметровСеанса(ИменаПараметровСеанса)
    Если ИменаПараметровСеанса = Неопределено Тогда
        // Инициализация всех параметров
    КонецЕсли;

    // Получаем ИД текущего пользователя ИБ
    ИДПользователя = ПользователиИнформационнойБазы.ТекущийПользователь().УникальныйИдентификатор;
    
    // Находим соответствующего пользователя в нашем справочнике
    НайденныйПользователь = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ", ИДПользователя);
    
    // Устанавливаем значение параметра сеанса
    ПараметрыСеанса.ТекущийПользователь = НайденныйПользователь;
КонецПроцедуры

Шаг 3: Настройка ограничения доступа (RLS)

Теперь, когда параметр сеанса заполнен, мы можем задать условие ограничения для справочника Номенклатура. В свойствах роли, отвечающей за доступ к номенклатуре, в разделе Ограничение доступа к данным для типа объекта Справочник.Номенклатура мы прописываем условие:

ГДЕ Ссылка В (
    ВЫБРАТЬ ТЧ.Ссылка 
    ИЗ Справочник.Номенклатура.Пользователи КАК ТЧ 
    ГДЕ ТЧ.Пользователь = &ТекущийПользователь
)

Здесь важно помнить: если ТекущийПользователь не найден (например, это администратор), условие может привести к тому, что пользователь не увидит вообще ничего. Обязательно предусмотрите проверку на пустое значение или логику доступа для администраторов.

Рекомендации по оптимизации

Если справочник Номенклатура содержит десятки или сотни тысяч записей, использование табличной части для хранения списка пользователей может существенно замедлить работу системы. Платформа при каждом открытии списка или формировании отчета будет выполнять соединение с таблицей табличной части.

1. Используйте Регистр Сведений: Вместо табличной части внутри справочника лучше создать РегистрСведений с измерениями Номенклатура и Пользователь. Это позволит системе использовать индексы для быстрого поиска.
2. Индексация: Обязательно убедитесь, что измерение Пользователь в регистре сведений является ведущим или проиндексированным, чтобы RLS отрабатывал максимально быстро.
3. Группы доступа: Для крупных проектов эффективнее связывать номенклатуру не с конкретными пользователями, а с группами доступа. Это облегчает администрирование и снижает количество записей, которые нужно проверять платформе при каждом обращении к базе данных.

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