Как отладить RLS в 1С: практическое руководство

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

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

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

Как устроен RLS и почему его трудно отлаживать

Ограничение доступа задаётся в роли на закладке «Ограничение доступа» для каждого права (чтение, добавление, изменение, удаление) и каждого объекта. Текст ограничения — это фрагмент условия на языке запросов, который платформа автоматически добавляет ко всем обращениям к таблице: в динамических списках, запросах, при программном чтении объектов.

Внутри ограничения используются шаблоны: конструкции вида #Параметр(1), ссылки на параметры сеанса (&ТекущийПользователь), обращения к функциональным опциям. Типовые конфигурации активно используют механизм «Группы доступа» и модуль УправлениеДоступом, где шаблоны хранятся централизованно.

Сложность отладки в том, что один объект может попадать под несколько ролей, и платформа объединяет их ограничения по правилу «ИЛИ» (доступ разрешён, если разрешает хотя бы одна роль). Поэтому избыточный доступ часто объясняется «лишней» ролью, а недостаточный — ошибкой в условии единственной роли.

Шаг 1. Воспроизведите проблему под нужным пользователем

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

Зафиксируйте конкретный сценарий: какой список или отчёт открывает пользователь, каких документов не хватает, какие лишние видны. Отладка «вообще» почти никогда не даёт результата — нужна воспроизводимая ситуация с конкретным документом, который должен быть виден, но не виден (или наоборот).

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

Шаг 2. Проверьте параметры сеанса

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

Параметры сеанса инициализируются в модуле сеанса (обработчик УстановкаПараметровСеанса). Поставьте там точку останова и войдите под проблемным пользователем — вы увидите, какие значения реально вычисляются. Обратите внимание: если параметр не инициализирован при первом обращении, платформа вызовет установку повторно, и логика должна это корректно обрабатывать.

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

// Проверка значений параметров сеанса из отладки или обработки
Сообщить(ПараметрыСеанса.ТекущийПользователь);
// Для типовых конфигураций:
Сообщить(ПараметрыСеанса.ДействующиеГруппыДоступа);

Шаг 3. Посмотрите итоговый запрос с ограничениями

Ключевой приём отладки — увидеть запрос в том виде, в каком его реально выполняет платформа, то есть с уже подставленными условиями RLS. Есть несколько способов.

Первый — консоль запросов с поддержкой режима ограничений (многие инструменты разработчика имеют флажок «Учитывать ограничения доступа»). Вставьте текст проблемного запроса, выполните его под пользователем с ограниченными правами и сравните результат с выполнением без RLS.

Второй способ — технологический журнал. Включите в нём события DBMSSQL или DBPostgreSQL (в зависимости от СУБД) совместно с контекстом, воспроизведите действие пользователя и найдите фактический SQL-запрос. В нём будут видны добавленные платформой соединения с таблицами групп доступа и условия вида WHERE ... IN (&П...). Это самый достоверный способ понять, что именно отсекло записи.

Третий способ — отладчик конфигуратора: остановитесь перед выполнением запроса и посмотрите текст в отладочном окне. Учтите, что в Запрос.Текст ограничения не видны — они добавляются платформой при компиляции, поэтому для анализа итогового текста технологический журнал надёжнее.

1. 1
   Настройте logcfg.xml: события DBMSSQL/DBPostgreSQL и CONTEXT, фильтр по пользователю или процессу
2. 2
   Перезапустите сервер 1С или rphost, чтобы конфигурация журнала применилась
3. 3
   Воспроизведите проблемное действие под нужным пользователем
4. 4
   Найдите в журнале запрос к нужной таблице и изучите добавленные условия и соединения
5. 5
   Сопоставьте условия с шаблоном ограничения в роли и значениями параметров сеанса
6. 6
   Отключите технологический журнал после анализа — он замедляет работу и быстро заполняет диск

Шаг 4. Проверьте шаблоны и текст ограничения

Откройте роль в конфигураторе, найдите объект и право, по которому возникла проблема, и внимательно прочитайте текст ограничения. Частые дефекты: неверный индекс параметра в #Параметр(2) вместо #Параметр(1), ссылка на несуществующий параметр шаблона, опечатка в имени поля, условие по неиндексированному полю.

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

Отдельно проверьте поля, по которым действует ограничение: в диалоге ограничения можно указать конкретные поля таблицы. Если ограничение назначено не на все поля, поведение при чтении объекта и при выборке в запросе может различаться, что выглядит как «то видит, то не видит».

Шаг 5. Проверьте производительность и избыточные соединения

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

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

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

Отладка RLS в типовых конфигурациях

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

Если пользователь состоит в нескольких группах доступа, действует объединение по ИЛИ: достаточно одной группы без ограничений, чтобы доступ стал полным. Типичный сценарий «видит лишнее» — пользователя добавили во вспомогательную группу ради одного отчёта, а она сняла ограничения по организациям.

Обратное — «не видит своё»: проверьте, что нужное значение (организация, склад) добавлено в разрешённые значения именно для того вида доступа, который используется в шаблоне объекта. Вид доступа определяется по тексту ограничения в роли, поэтому при нестандартных доработках шаблон и настройки профиля могут разойтись.

FAQ: частые вопросы по отладке RLS