Почему не работает ограничение доступа (RLS) по пользователю в УТ 11 и как это исправить?

← На главную

При настройке прав доступа в 1С:Управление торговлей 11 администраторы часто сталкиваются с ситуацией, когда ограничение по «Подразделениям» или «Организациям» отрабатывает корректно, а ограничение по «Пользователям» (чтобы менеджер видел только свои документы) не дает никакого эффекта. В этой статье мы подробно разберем, почему стандартные настройки RLS (Record Level Security) ведут себя именно так, и рассмотрим способы решения этой задачи.

Почему стандартный RLS по пользователю «не видит» документы?

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

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

Способ 1. Доработка шаблонов ограничений в ролях

Рассмотрим самый надежный, но трудоемкий метод — добавление шаблона ограничения в конкретную роль. Если нам нужно, чтобы ограничение заработало для документа Заказ клиента, нам придется изменить текст ограничения в правах на Чтение, Добавление и Изменение.

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


#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
    #ДляОбъекта("")
#Иначе
    #ПоЗначениям( "Документ.ЗаказКлиента","Чтение","",
    "Организации","Организация",
    "Склады","Склад",
    "ГруппыПартнеров","Партнер",
    "Подразделения","Подразделение",
    "Пользователи","Менеджер", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","" )
#КонецЕсли

Разберем, что делает этот код. Если в системе включен универсальный механизм, система использует внутренние алгоритмы БСП. Если же нет — вступает в силу функция #ПоЗначениям. В ней мы явно указываем, что поле Менеджер документа ЗаказКлиента должно проверяться по виду доступа Пользователи.

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

Способ 2. Использование универсального механизма ограничения доступа

Начиная с версий УТ 11.4.10, приоритетным является универсальный механизм RLS. Он работает быстрее, так как не вычисляет права «на лету» при каждом запросе к базе, а использует заранее подготовленные данные в специальных регистрах.

Выясним, как заставить его работать:

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

Различие между полями «Автор» и «Менеджер»

Частая ошибка при настройке RLS — путаница в полях документа. Рассмотрим ситуацию: вы настроили ограничение по пользователю, но менеджер все равно видит чужие документы. Проверьте, какое поле указано в шаблоне или настройках системы: Автор или Менеджер.

Автор — это тот, кто физически создал запись в базе (заполняется автоматически системой).
Менеджер — это ответственное лицо, выбранное в документе (может быть изменено вручную).

Если в шаблоне RLS прописано ограничение по полю Менеджер, а в документе это поле не заполнено, ограничение может не сработать, и документ останется видимым для всех. Убедитесь, что в ваших документах реквизит, по которому идет фильтрация, обязателен к заполнению.

Регламентные задания и актуальность данных

Если вы внесли изменения в настройки прав, но эффекта нет, проанализируем работу регламентных заданий. В универсальном механизме RLS права не обновляются мгновенно. За это отвечают задания:

Обновление прав доступа (оперативное);
Заполнение данных для ограничения доступа.

Пока эти задания не завершат свою работу, пользователь будет видеть данные в соответствии со «старыми» правами. Посмотреть статус обновления прав можно в отчете Панель администрирования — Управление доступом — Отчет «Результаты обновления прав доступа». Для ускорения процесса можно применить обработку для точечного пересчета прав доступа пользователя.

Диагностика через отчет «Права доступа»

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

В этом отчете можно увидеть, какая именно роль дает право на чтение объекта. Помните золотое правило 1С: Разрешающее право имеет приоритет. Если у пользователя есть две роли, одна из которых ограничивает доступ к заказам по менеджеру, а другая (например, какая-нибудь сервисная роль «Чтение всех заказов») разрешает чтение без условий — пользователь увидит все документы. Всегда проверяйте состав ролей на наличие «лишних» прав.