Почему не работает RLS в 1С:Управление торговлей 11.3 и как правильно настроить ограничения прав

← На главную

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

Принцип объединения ролей в платформе 1С:Предприятие

Главная и наиболее частая причина, по которой написанное ограничение RLS не дает видимого эффекта, заключается в механизме комбинации прав платформы. В платформе 1С права пользователей по всем назначенным им ролям объединяются по логическому условию ИЛИ.

Рассмотрим, как это работает на практике:

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

Проанализируем пример: назначение пользователю с Полными правами дополнительной роли с жесткими ограничениями RLS никак не ограничит его доступ, так как Полные права предоставляют неограниченный доступ ко всем объектам метаданных.

Использование штатных шаблонов RLS в типовых конфигурациях

В современных типовых решениях (включая УТ 11.3, ERP, КА) дописывание собственных условий RLS в роли через параметры сеанса вручную не рекомендуется. В конфигурациях используется штатный механизм подсистемы управления доступом БСП. Назначение ограничений выполняется с помощью шаблона #ПоЗначениям.

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


#ПоЗначениям( "Документ.РеализацияТоваровУслуг","Чтение","",
"Организации","Организация",
"Склады","Склад",
"Подразделения","Подразделение",
"ГруппыПартнеров","Партнер", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","" )

Разберем параметры этого шаблона:

Название вида доступа во множественном числе (например, "Подразделения", "Склады") — это имя вида доступа, зарегистрированное в подсистеме управления доступом. Оно отображается в настройках профилей групп доступа.
Имя реквизита в единственном числе (например, "Подразделение", "Склад") — это имя конкретного реквизита документа, по которому проверяются права.

Пошаговая настройка ограничений доступа через профили и группы доступа

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

Перейдем в раздел Администрирование — Настройки пользователей и прав — Группы доступа.
Откроем или создадим новый Профиль групп доступа (например, на базе штатного профиля «Менеджер по продажам»).
На вкладке Ограничения доступа найдем нужный вид доступа, например Подразделения или Склады.
Установим вид ограничения: Все разрешены, исключения назначаются в группах доступа или Все запрещены, исключения назначаются в группах доступа.
Создадим Группу доступа на основе этого профиля, выберем участника (пользователя или группу пользователей) и на вкладке ограничений внесем список разрешенных или запрещенных подразделений/складов из справочника «Структура предприятия».

Системные проверки: почему RLS может не работать даже при верных настройках

Если настройки прав в профилях заданы правильно, но пользователь всё равно видит лишние записи или ограничения не срабатывают, проанализируем следующие системные факторы:

Функциональная опция ограничений: Убедимся, что в разделе администрирования включена опция Ограничивать доступ на уровне записей. Если этот флаг снят, платформа игнорирует любые шаблоны ограничений в ролях.
Актуализация ключей доступа: В УТ 11.3 права рассчитываются через служебные регистры сведений (ключи доступа). Если фоновое задание обновления ключей доступа работает с задержкой или отключено, изменения прав не применятся сразу. В этом случае требуется запустить пересчет прав через сервисные обработки подсистемы управления доступом.
Инициализация параметров сеанса в кастомных ролях: Если ограничения создаются вручную, собственному параметру сеанса необходимо явно задавать значение в процедуре УстановкаПараметровСеанса модуля сеанса. В противном случае обращение к незаполненному параметру вызовет ошибку СУБД или некорректное выполнение запроса RLS.