Как настроить RLS для ограничения выбора контрагента в документах при сохранении доступа к просмотру?

Понимание основ механизма RLS

Прежде чем приступать к реализации, проанализируем, как именно работает RLS (Restriction Level Security). Многие разработчики ошибочно полагают, что это «фильтр», который можно наложить поверх уже существующих прав. На самом деле RLS — это уточнение условий доступа к записям конкретной таблицы. Важнейший принцип, который нужно усвоить: права в 1С обладают свойством аддитивности (сложения). Если у пользователя есть хотя бы одна роль, разрешающая доступ к объекту, этот доступ будет предоставлен, даже если в другой роли вы прописали жесткое ограничение.

Разбор проблемы «сложения прав»

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

Реализация ограничения доступа: пошаговое руководство

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

1. Использование параметров сеанса: Настройте ПараметрыСеанса, которые будут хранить контекст текущего пользователя. Это позволит системе «понимать», какие данные доступны конкретному сеансу в текущий момент времени. Устанавливайте значение параметра при начале работы системы в МодулеСеанса.
2. Создание регистра сведений: Создайте РегистрСведений (например, «ДоступныеКонтрагентыПользователей»), в котором будет храниться связь «Пользователь — Контрагент».
3. Написание правила RLS: В шаблоне ограничения доступа для таблицы ЗаказКлиента пропишите условие, проверяющее наличие связи между пользователем и контрагентом в созданном регистре. Если связи нет — система заблокирует запись документа.

Пример логики запроса в шаблоне ограничения:

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

Почему RLS на справочнике недостаточно?

Частая ошибка — пытаться ограничить доступ только на уровне Справочник.Контрагенты. RLS накладывается на конкретные таблицы. Если вы ограничите доступ к контрагенту, пользователь перестанет видеть его везде. Однако, если вы хотите оставить видимость в списке, но запретить использование в заказах, необходимо накладывать ограничение именно на таблицу документа ЗаказКлиента. В момент попытки записи документа система проверит, имеет ли право данный пользователь использовать этого контрагента. Если нет — возникнет исключение «Нарушение прав доступа».

Рекомендации по подходу к правам

Для крупных конфигураций и сложных систем лучше всего придерживаться подхода, реализованного в БСП (Библиотека стандартных подсистем):

• Создавайте микро-роли: каждая роль отвечает за одно конкретное право или ограничение.
• Используйте профили групп доступа: они объединяют микро-роли в логические наборы. Это избавляет от необходимости «перекрытия» прав, так как одна роль не конфликтует с другой, а дополняет её до нужной функциональности.

Такой подход позволяет избежать проблем с обновлением конфигурации (если вы используете Расширения для добавления новых объектов метаданных) и делает систему прав прозрачной для администратора.

Заключение

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

• Всегда проверяйте результат под пользователем с минимальными правами.
• Помните, что RLS — это условие WHERE, добавляемое к запросу к СУБД, поэтому сложные запросы в условиях могут замедлить систему.
• Используйте ПараметрыСеанса для передачи контекста.
• Не забывайте, что «Полные права» всегда имеют приоритет над любыми ограничениями RLS.

Двигайтесь последовательно: от настройки параметров сеанса к созданию регистров, и вы сможете реализовать гибкое управление доступом даже в закрытой типовой конфигурации.