Как в УТ 10.3 установить ограничение доступа к документам по основному складу пользователя

← На главную

В типовой конфигурации «Управление торговлей 10.3» часто возникает задача разграничения прав доступа. Одной из самых популярных подзадач является ограничение видимости документов (например, РеализацияТоваровУслуг) таким образом, чтобы менеджер видел только те операции, которые относятся к его основному складу. Рассмотрим, как это реализовать с помощью механизма RLS (Record Level Security), проанализируем различные подходы и выберем наиболее эффективный.

Постановка задачи и анализ ситуации

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

Способ 1. Использование соединения (JOIN) в шаблоне RLS

Этот метод считается наиболее прямолинейным. Мы создаем шаблон ограничения, который при каждом обращении к базе данных будет «подглядывать» в регистр настроек. Разберем логику построения такого запроса. Нам необходимо соединить текущую таблицу документа с регистром настроек по значению склада.

Рассмотрим пример шаблона RLS, который можно применить для права «Чтение» у роли менеджера:


ТекущаяТаблица
ИЗ
    #ТекущаяТаблица КАК ТекущаяТаблица
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПользователей КАК НастройкиПользователей
    ПО ТекущаяТаблица.Склад = НастройкиПользователей.Значение
ГДЕ
    НастройкиПользователей.Пользователь = &ТекущийПользователь
    И НастройкиПользователей.Настройка = Значение(ПланВидовХарактеристик.НастройкиПользователей.ОсновнойСклад)

Плюсы этого метода:

Не требует внесения изменений в модули конфигурации (только в права доступа).
Работает «из коробки», используя стандартные параметры, такие как &ТекущийПользователь.

Минусы:

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

Способ 2. Оптимизация через параметры сеанса (Рекомендуемый)

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

Шаг 1. Создание параметра сеанса.
В дереве метаданных перейдем в ветку Общие -> Параметры сеанса. Создадим новый параметр ТекущийОсновнойСклад с типом СправочникСсылка.Склады.

Шаг 2. Заполнение параметра при старте.
В модуле сеанса необходимо прописать процедуру УстановкаПараметровСеанса. Проанализируем пример кода для заполнения значения:


Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   НастройкиПользователей.Значение КАК Склад
        |ИЗ
        |   РегистрСведений.НастройкиПользователей КАК НастройкиПользователей
        |ГДЕ
        |   НастройкиПользователей.Пользователь = &Пользователь
        |   И НастройкиПользователей.Настройка = &Настройка";
    
    Запрос.УстановитьПараметр("Пользователь", ПараметрыСеанса.ТекущийПользователь);
    Запрос.УстановитьПараметр("Настройка", ПланыВидовХарактеристик.НастройкиПользователей.ОсновнойСклад);
    
    Результат = Запрос.Выполнить();
    Если Не Результат.Пустой() Тогда
        Выборка = Результат.Выбрать();
        Выборка.Следующий();
        ПараметрыСеанса.ТекущийОсновнойСклад = Выборка.Склад;
    Иначе
        ПараметрыСеанса.ТекущийОсновнойСклад = Справочники.Склады.ПустаяСсылка();
    КонецЕсли;
КонецПроцедуры

Шаг 3. Настройка RLS.
Теперь текст ограничения в роли будет выглядеть максимально просто и эффективно:

ГДЕ Склад = &ТекущийОсновнойСклад

Такой запрос отрабатывает мгновенно, так как значение склада уже находится в оперативной памяти сервера приложений 1С.

Способ 3. Использование встроенных механизмов групп доступа

Прежде чем приступать к программированию, посмотрим на штатные возможности УТ 10.3. В программе существует механизм «Ограничение прав доступа на уровне записей». Рассмотрим, как его задействовать:

Перейдем в меню «Сервис — Настройки пользователя — Ограничение прав доступа на уровне записей».
Включим флаг использования ограничений.
В справочнике Группы доступа к объектам создадим группы для складов.
Назначим пользователям соответствующие группы.

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

Важные нюансы и обработка исключений

При внедрении RLS важно проанализировать ситуацию, когда у пользователя не заполнен основной склад. Если использовать строгое равенство Склад = &ТекущийОсновнойСклад, то пользователь с пустой настройкой не увидит ни одного документа. Чтобы избежать этого, можно модифицировать условие:


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

Также не забудем про право «Добавление» и «Изменение». Ограничение только на «Чтение» позволит пользователю создать документ на любой склад, но сразу после записи документ исчезнет из его видимости, что вызовет путаницу. Продублируйте условия RLS для всех ключевых прав.

Напоследок отметим влияние на отчеты. Если вы накладываете ограничение на документ РеализацияТоваровУслуг, но не накладываете на регистр накопления Продажи, пользователь всё равно сможет увидеть суммы оборотов по «чужим» складам через отчеты. Поэтому для полной изоляции данных рекомендуется применять аналогичные шаблоны RLS и к соответствующим регистрам сведений и накопления.