Как ограничить доступ к спецификациям номенклатуры в 1С:УНФ при помощи RLS?

В процессе работы с конфигурацией «1С:Управление нашей фирмой» (УНФ) часто возникает бизнес-задача: скрыть определенные спецификации (составы изделий) от глаз рядовых сотрудников. Это может быть связано с защитой производственных секретов или разделением зон ответственности. Нам нужно добиться того, чтобы пользователь не только не мог открыть спецификацию, но и не видел её наименование в списках и документах (например, в «Заказе на производство»), получая вместо этого сообщение «Объект не обнаружен» или пустую ссылку.

В данной статье мы подробно разберем, как реализовать это ограничение с помощью механизма RLS (Row Level Security), рассмотрим нюансы «производительного режима» доступа и решим типичные ошибки, возникающие при поиске данных.

Принцип работы ограничения на уровне записей

Механизм RLS позволяет наложить фильтр на уровне базы данных. Если у пользователя нет прав на конкретную запись справочника Спецификации, то платформа 1С просто «вырезает» эту запись из всех выборок. Для пользователя это выглядит так, будто объекта не существует вовсе. Если такая спецификация уже выбрана в документе, вместо её названия пользователь увидит стандартную надпись «<Объект не обнаружен>».

Проанализируем базовый запрос для ограничения доступа, который вставляется в роль в конфигураторе (на действие «Чтение»):

Ограничение.Текст = 
"РазрешитьЧтениеИзменение 
|ГДЕ 
| ЭтоГруппа 
| ИЛИ ЗначениеРазрешено(Ссылка)";

Рассмотрим, что делает этот код: мы разрешаем чтение групп (чтобы иерархия справочника не ломалась) и разрешаем работу с теми ссылками, которые проходят проверку через стандартные профили доступа. Однако при использовании современных версий УНФ на базе БСП (Библиотеки стандартных подсистем), простого запроса в конфигураторе бывает недостаточно.

Особенности производительного режима RLS

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

1. Проверим, включено ли использование RLS в настройках программы (Администрирование — Настройки пользователей и прав).
2. Запустим регламентное задание «Обновление доступа на уровне записей». Пока оно не завершится, новые правила ограничения не вступят в силу.
3. В некоторых случаях может потребоваться полная очистка кэша данных доступа через обработку «Панель администрирования БСП».

Исправление ошибки «Недостаточно прав» при поиске по строке

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

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

Чтобы исправить это, нам необходимо найти в модуле менеджера справочника Спецификации (или Номенклатура, если поиск идет через неё) соответствующий запрос и обязательно добавить ключевое слово РАЗРЕШЕННЫЕ:

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

Как показывает практика, часто программисты забывают про это слово именно в специализированных обработчиках. Также убедимся, что для пользователя оставлены права на чтение реквизитов Ссылка, ПометкаУдаления и ЭтоГруппа, иначе платформа может блокировать даже базовые операции отображения объектов.

Влияние на бизнес-логику и отчеты

Важно понимать, что жесткое ограничение прав через RLS — это «хирургическое» вмешательство. Посмотрим на возможные побочные эффекты в УНФ:

• Производственные документы: Если бухгалтер или мастер цеха пытается провести документ «Производство», а в нем указана «запрещенная» спецификация, алгоритмы расчета себестоимости могут не сработать, так как программа не сможет программно прочитать состав материалов.
• Автозаполнение: Если в настройках номенклатуры указана основная спецификация, к которой у пользователя нет доступа, при выборе этой номенклатуры в заказе поле «Спецификация» останется пустым. Это не ошибка кода, а прямое следствие ограничения прав.
• Отчеты: При формировании отчетов по выпуску продукции или складских остатков в разрезе спецификаций, строки с закрытыми данными будут просто исключены. Итоговые суммы по отчету могут «не сходиться» с общими данными, если не учитывать фактор прав доступа.

Рекомендация по использованию шаблонов БСП

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

Подведем итог: для успешного ограничения доступа к спецификациям в УНФ нам необходимо корректно прописать условия в ролях, убедиться в обновлении данных в «производительном режиме» и тщательно проверить все обработчики ОбработкаПолученияДанныхВыбора на наличие ключевого слова РАЗРЕШЕННЫЕ.