Как ограничить доступ к определенной папке номенклатуры в 1С:Управление торговлей 10.3?

← На главную

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

Почему стандартные фильтры форм не подходят

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

Уязвимость в отчетах: интерфейсный фильтр не влияет на выполнение запросов в отчетах. Пользователь сможет легко сформировать продажи или остатки по скрытой номенклатуре.
Обход через поиск по строке: при вводе наименования или артикула непосредственно в табличной части документа поиск по строке отобразит запрещенные элементы.
Доступность через связанные объекты: данные останутся видимыми в регистрах накопления и документах движения.

Единственным штатным механизмом платформы «1С:Предприятие 8», позволяющим полностью скрыть записи на уровне базы данных, является RLS (Record Level Security).

Архитектурная декомпозиция ролей

В типовой конфигурации «Управление торговлей 10.3» нет готового ограничения доступа на чтение по номенклатуре (присутствуют только механизмы по организациям и контрагентам). Чтобы не вносить условия ограничения в каждую типовую роль пользователей, применим принцип декомпозиции прав:

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

Реализация условия RLS через параметры сеанса

Рассмотрим пример ограничения, при котором запрещенные элементы определяются динамически и помещаются в параметр сеанса. Создадим параметр сеанса ПараметрСеанса1 с типом ФиксированныйМассив.

В модуле сеанса в процедуре УстановкаПараметровСеанса заполняем массив ссылками на папки или элементы, к которым доступ должен быть закрыт:


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

Теперь в конфигураторе для созданной роли на вкладке «Права» у справочника Номенклатура на право Чтение задаем текст ограничения:


ГДЕ НЕ Ссылка В (&ПараметрСеанса1)
  И НЕ Родитель В (&ПараметрСеанса1)

Особенности и подводные камни фильтрации по иерархии

Разберем, с какими проблемами можно столкнуться при использовании условия НЕ Родитель В (...):

Глубина вложенности: проверка НЕ Родитель В (...) отсекает только элементы первого уровня вложенности под указанной папкой. Если внутри запрещенной группы есть подпапки, то элементы внутри этих подпапок отобразятся в поиске по строке и плоских списках, так как их непосредственный Родитель не входит в параметр сеанса.
Проблема оператора В ИЕРАРХИИ: использование конструкции ГДЕ НЕ Ссылка В ИЕРАРХИИ (&ПараметрСеанса1) в RLS решает вопрос любой глубины вложенности, однако создает огромную нагрузку на СУБД. В высоконагруженных базах это приводит к критическому замедлению динамических списков и отчетов.
Сбои при проведении документов: типовые алгоритмы проведения документов в конфигурации «Управление торговлей 10.3» выполняются в контексте прав пользователя без переключения в привилегированный режим. Если в документе (или в связанных регистрах) встретится запрещенная позиция, проведение завершится ошибкой Нарушение прав доступа.
Надписи <Объект не найден>: ограничение права на чтение приводит к тому, что в старых документах и отчетах скрытая номенклатура будет отображаться как битая ссылка вида <Объект не найден> [GUID].

Проверенные практики реализации ограничений

Для создания стабильного решения рекомендуется использовать методы, заложенные в более развитых конфигурациях (например, «Комплексная автоматизация 1.1» или «Управление производственным предприятием 1.3»):

Группы доступа номенклатуры: создается отдельный справочник ГруппыДоступаНоменклатуры, ссылка на который добавляется реквизитом в справочник Номенклатура. Ограничение RLS строится не по иерархии папок, а по точному значению этого реквизита. Это позволяет СУБД использовать стандартные индексы без рекурсивного разбора дерева.
Денормализация иерархии: если требуется жесткая связь с папками, создается непериодический регистр сведений, где хранятся пары «Элемент — ВсеВышестоящиеРодители». RLS соединяется с этим регистром обычным соединением без использования медленного оператора В ИЕРАРХИИ.
Ограничение только на запись: если цель — исключить выбор устаревшей или помеченной на удаление номенклатуры в новые документы, безопаснее ограничить права на Изменение и Добавление, сохранив Чтение. В этом случае проведение документов и формирование исторических отчетов продолжат работать корректно, а пользователи не смогут использовать позиции в новых операциях.