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

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

Вариант 1. Использование механизма RLS (Record Level Security)

Механизм RLS (ограничение доступа на уровне записей) позволяет наложить фильтр на данные непосредственно на уровне SQL-запроса платформы. Это наиболее надежный метод, так как он работает «под капотом» и ограничивает доступ вне зависимости от того, как пользователь пытается изменить данные (через форму или обработкой).

Проанализируем особенности настройки RLS для иерархических справочников:

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

Вариант 2. Программный контроль в модуле объекта

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

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

Алгоритм реализации в обработчике ПередЗаписью:

1. Проверим, является ли текущий пользователь администратором (полные права). Если да — разрешаем запись без проверок.
2. Определим родителя (папку), в которую записывается элемент.
3. Выполним запрос к регистру сведений, где хранятся настройки прав доступа, чтобы понять, разрешено ли текущему пользователю редактирование объектов в этой группе.
4. Если доступа нет, установим параметр Отказ = Истинный и выведем предупреждение.

Пример логики для обработчика ПередЗаписью:

Процедура ПередЗаписью(Отказ)
    Если ЭтоНовый() Тогда
        ПроверитьДоступКПапке(Родитель, Отказ);
    Иначе
        // Проверяем доступ как к текущей папке, так и к той, 
        // в которую, возможно, перемещают элемент
        ПроверитьДоступКПапке(Родитель, Отказ);
        // Дополнительно можно проверить, не изменился ли Родитель
    КонецЕсли;
КонецПроцедуры

Вариант 3. Контроль при заполнении и копировании

Чтобы повысить удобство работы пользователей, важно пресекать попытки несанкционированного создания данных еще на этапе открытия формы. Для этого стоит задействовать процедуру ОбработкаЗаполнения.

Разберем ситуацию: менеджер нажимает кнопку «Добавить», находясь в чужой папке. Система должна сразу выдать ошибку или подставить разрешенную папку. Также необходимо предусмотреть обработку копирования элементов, чтобы пользователь не мог обойти запрет, скопировав чужой товар в свою группу без прав на родительскую директорию.

Важные технические нюансы и ограничения

Рассмотрим специфические моменты, с которыми мы столкнемся при внедрении данных доработок в УТ 10.3:

1. Отображение в отчетах: Если вы используете RLS на чтение, то в стандартных отчетах (например, «Ведомость по товарам на складах») пользователи могут видеть пустые строки или ошибки доступа, если в выборку попадают товары из закрытых папок. Если задача стоит только в ограничении редактирования, лучше настраивать RLS только на действие «Изменение».
2. Обмен данными и торговое оборудование: Выясним причину возможных сбоев при обмене данными. Если обмен (например, с сайтом или ТСД) запускается от имени пользователя, у которого ограничены права, часть номенклатуры может просто не выгрузиться. Для «служебных» пользователей, под которыми работают фоновые задания и обмены, ограничения RLS должны быть отключены.
3. Глубина вложенности: Если вы решите использовать иерархический запрос в RLS без кэширования, помните, что платформа 8.2/8.3 в обычных формах чувствительна к глубине вложенности папок. Оптимально заранее подготавливать список разрешенных групп и хранить его в ПараметрыСеанса при старте системы.

Итоги

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