Почему не работает ограничение доступа (RLS) для Заказа клиента и как это исправить

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

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

Природа ограничений 1С: Приоритет разрешающих ролей

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

Разберем ситуацию на примере. Допустим, у пользователя есть две роли:

1. Роль 1 (Ограниченная): Дает право на чтение заказов с условием ГДЕ Менеджер = &ТекущийПользователь.
2. Роль 2 (Общая): Дает право на чтение тех же заказов, но без условий (пустой RLS).

В результате пользователь получит полный доступ ко всем заказам, так как Роль 2 разрешает то, что пытается ограничить Роль 1. Именно поэтому крайне важно убедиться, что у пользователя нет «лишних» прав, которые он мог получить неявным путем.

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

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

Для детального анализа воспользуемся встроенным инструментом БСП:

1. Перейдем в раздел Администрирование — Настройки пользователей и прав.
2. Откроем карточку конкретного Пользователя.
3. На панели навигации выберем пункт Права доступа.
4. Нажмем кнопку Отчет по правам доступа.
5. Важно: в настройках отчета установите флаг Расширенный.

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

Особенности работы БСП: Скрытые и служебные роли

Многие разработчики считают «косяком» интерфейса то, что список ролей в Конфигураторе не совпадает с тем, что они видят в Группах доступа. На самом деле — это архитектурная особенность БСП. Рассмотрим, как это работает:

Когда вы добавляете пользователя в группу доступа, система программно назначает ему не только основные роли, указанные в профиле, но и целый ряд служебных ролей (например, БазовыеПрава, ЗапускТонкогоКлиента и т.д.). В некоторых случаях, если используется сложная иерархия профилей или предопределенные группы доступа (например, «Все пользователи»), права могут суммироваться неожиданным образом.

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

Производительный RLS и регистры разрешенных значений

В современных версиях УТ 11, ERP и КА используется так называемый «Производительный RLS». В отличие от классического варианта, где условие ГДЕ пристыковывается к каждому SQL-запросу, производительный режим использует заранее рассчитанные таблицы прав (регистры сведений).

Посмотрим, как это влияет на вашу задачу:

1. Если вы написали условие RLS вручную в коде роли: ГДЕ Менеджер = &ТекущийПользователь, а система настроена на производительный режим, ваше условие может быть проигнорировано.
2. Система ожидает использования стандартных шаблонов БСП, таких как #ПоЗначениям(...).
3. После любого изменения состава ролей или текстов RLS необходимо обновлять данные в регистрах.

Для решения этой проблемы рекомендуется проверить регламентное задание «Обновление прав доступа». Если оно зависло или не выполняется, изменения в правах не вступят в силу для динамических списков и отчетов.

Пример правильного написания условия доступа

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

Типовой код ограничения в роли может выглядеть так:

ЗаказКлиента ГДЕ 
    Менеджер = &ТекущийПользователь
    ИЛИ Автор = &ТекущийПользователь

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

#ПоЗначениям( "Документ.ЗаказКлиента","Чтение","",
"ГруппыОплаты","Ссылка",
"Менеджеры","Менеджер", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","" )

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

Резюме и план действий

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

1. Проверьте дублирующие роли: Используйте «Отчет по правам доступа» (расширенный), чтобы найти роль, дающую доступ без RLS.
2. Очистите роли в Конфигураторе: Если вы видите там роли, которых нет в интерфейсе, попробуйте временно убрать пользователя из всех групп доступа и убедиться, что список ролей в Конфигураторе очистился (за исключением базовых).
3. Используйте типовые механизмы: В УТ 11 лучше настраивать доступ через Группы доступа номенклатуры, Группы доступа партнеров или подразделения, используя стандартные профили, вместо написания сырого SQL-кода в ролях.
4. Перезапустите сеанс: Параметры сеанса и кэш прав обновляются при входе пользователя.
5. Проверьте динамические списки: Если данные отображаются в списке, убедитесь, что это не результат работы привилегированного модуля. Динамические списки всегда накладывают RLS, если запрос к основной таблице не обернут в функции, отключающие проверку прав (что в типовых формах заказов встречается редко).

Соблюдение этих правил и понимание того, что в 1С права всегда «суммируются», позволит вам эффективно управлять доступом даже в таких сложных конфигурациях, как УТ 11.