Как проверить RLS (ограничение доступа на уровне записей) в 1С

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

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

Ниже — рабочий порядок проверки, который подходит для типовых конфигураций (УТ, ERP, БП, ЗУП) и для самописных решений, где RLS настроен вручную.

Убедитесь, что RLS вообще включён в роли

Откройте конфигуратор и найдите роль, назначенную пользователю. В дереве прав по объекту (например, документу «Реализация товаров и услуг») у права «Чтение» и «Добавление/Изменение» есть колонка «Ограничение доступа». Если ячейка пуста — RLS для этого объекта не действует, и фильтрации записей не будет в принципе.

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

Проверьте шаблон ограничения и параметры сеанса

Типовые шаблоны RLS опираются на параметры сеанса — например, «ТекущийПользователь», «ГруппыДоступа» или список разрешённых организаций. Если параметр сеанса не заполнен или заполнен не тем значением, ограничение либо отсекает всё, либо пропускает всё.

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

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

1. 1
   Откройте роль пользователя и проверьте заполнение колонки «Ограничение доступа» у прав на чтение и изменение нужных объектов
2. 2
   Изучите текст шаблона RLS и выпишите, какие параметры сеанса он использует
3. 3
   Проверьте в отладчике, чему равны эти параметры при входе пользователя
4. 4
   Убедитесь, что в настройках конфигурации включён режим ограничения доступа на уровне записей
5. 5
   Запустите сеанс от имени пользователя и выполните тестовую выборку данных

Протестируйте под учётной записью пользователя

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

Откройте список документов или справочник, на который действует RLS, и сверьте состав записей с ожидаемым. Затем выполните простой запрос через консоль запросов (если она доступна пользователю) или через внешнюю обработку: выборка должна вернуть только разрешённые записи.

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

Найдите ошибки в тексте шаблона RLS

Шаблон ограничения — это фрагмент языка запросов со своими макрокомандами: #ПоЗначениям, #ПоНаборамЗначений, #ПоЗначениямРасширенный и другими. Ошибка в имени поля, параметра или в логике соединений приводит к тому, что запрос либо не выполняется, либо фильтрует неправильно.

Типичный признак синтаксической ошибки — пользователь вообще не может открыть список: платформа выдаёт сообщение об ошибке запроса при обращении к таблице. Логическая ошибка коварнее: список открывается, но состав записей неверный.

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

// Пример проверки через запрос в консоли (от имени пользователя)
ВЫБРАТЬ
    РеализацияТоваровУслуг.Ссылка,
    РеализацияТоваровУслуг.Организация
ИЗ
    Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ГДЕ
    РеализацияТоваровУслуг.Дата >= &НачалоПериода

Типовые конфигурации: проверка групп доступа

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

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

Также проверьте журнал регистрации: ошибки обновления RLS и установки параметров сеанса фиксируются там с указанием пользователя и текста ошибки. Это быстрый способ локализовать проблему без отладчика.

Ограничения и риски при самостоятельной проверке

Изменение шаблонов RLS — это модификация конфигурации. Перед правкой сделайте выгрузку базы или убедитесь в наличии свежей резервной копии: ошибочный шаблон может закрыть доступ к данным всем пользователям сразу после обновления конфигурации базы данных.

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

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

FAQ