Как в динамическом списке 1С скрыть строки с «Объект не найден» при ограничении прав (RLS)?

В процессе разработки на платформе 1С, особенно при работе с расширениями и настройкой прав доступа (RLS), часто возникает ситуация, когда в динамическом списке вместо данных отображается системная надпись <Объект не найден>. Это происходит, когда у пользователя есть права на чтение основной записи, но нет прав на связанный объект, на который она ссылается. Давайте подробно разберем, почему так происходит и как сделать, чтобы такие строки просто не выводились в список.

Анализ проблемы: почему появляется «Объект не найден»?

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

1. Запрос к основной таблице. Динамический список выполняет запрос к основной таблице (нашему регистру сведений). Поскольку у пользователя есть права на чтение записей регистра, все они попадают в первоначальную выборку. Ключевое слово ВЫБРАТЬ РАЗРЕШЕННЫЕ в этом случае не отфильтрует строки, так как оно применяется именно к основной таблице запроса, а к ней доступ есть.
2. Получение представления ссылочных полей. На втором этапе, при выводе данных на форму, платформа пытается получить представление для каждого ссылочного поля. То есть для колонки «Документ» она обращается к самому документу, чтобы получить его номер, дату и т.д.
3. Проверка прав на связанный объект. В момент обращения к документу снова срабатывает механизм проверки прав (RLS), но уже для объекта-документа. Если доступ к конкретному документу (например, расчетному) запрещен, платформа не может получить его представление и выводит системное сообщение <Объект не найден>.

В результате пользователь видит строки, данные в которых ему недоступны, что выглядит неаккуратно и может вызывать вопросы. Наша задача — отфильтровать такие строки еще на этапе выполнения запроса.

Решение: правильная фильтрация в запросе динамического списка

Простое решение заключается в том, чтобы заставить платформу проверить права на связанный объект еще на этапе выполнения основного запроса. Этого можно добиться, если в запросе обратиться не к самой ссылке, а к одному из ее реквизитов через точку. Когда система видит такое обращение в условии ГДЕ, она вынуждена выполнить соединение (JOIN) с таблицей документов, и в этот момент RLS отсекает те записи, на которые у пользователя нет прав.

Для пользователя с ограниченными правами недоступные ему документы как бы не существуют. Поэтому при попытке получить реквизит такой «несуществующей» ссылки (например, .Ссылка) результат будет NULL. Этим мы и воспользуемся.

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

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    Регистр.Документ КАК Документ,
    Регистр.СтатусОтправки КАК СтатусОтправки,
    Регистр.Ответственный КАК Ответственный
ИЗ
    РегистрСведений.УведомлениеОКадровыхИзменениях КАК Регистр

Чтобы отфильтровать строки с недоступными документами, добавим в него условие в секцию ГДЕ. Важно обратиться именно к реквизиту ссылки, а не к самому полю.

Неправильный вариант: ГДЕ НЕ Регистр.Документ ЕСТЬ NULL. Это условие не сработает, потому что само поле в регистре заполнено, оно не NULL, просто ссылается на недоступный объект.

Правильный вариант:

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    Регистр.Документ КАК Документ,
    Регистр.СтатусОтправки КАК СтатусОтправки,
    Регистр.Ответственный КАК Ответственный
ИЗ
    РегистрСведений.УведомлениеОКадровыхИзменениях КАК Регистр
ГДЕ
    НЕ Регистр.Документ.Ссылка ЕСТЬ NULL

Что здесь происходит?

Обращение Регистр.Документ.Ссылка заставляет систему выполнить «разворачивание» ссылки на документ. На этом этапе вступает в силу RLS. Если у пользователя нет прав на документ, система считает его несуществующим, и результат выражения Регистр.Документ.Ссылка будет равен NULL. Наше условие НЕ ... ЕСТЬ NULL отсечет такие строки, и в итоговый результат запроса они не попадут.

Важный нюанс: RLS для объектов в расширениях

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

Обычно это требует следующих шагов:

1. Настройка ролей. В расширении нужно либо создать новую роль, либо заимствовать существующую и настроить для нее права на новый регистр.
2. Настройка шаблонов ограничений. Для этой роли на вкладке «Шаблоны ограничений» необходимо прописать текст запроса, который будет ограничивать доступ. Часто для этого можно адаптировать стандартные шаблоны из типовых ролей. Например, ограничить доступ по организациям или группам доступа физических лиц.
3. Интеграция с Библиотекой стандартных подсистем (БСП). Чтобы RLS для новых объектов работало эффективно, особенно в производительном режиме, может потребоваться доработка в коде. Например, добавить ваш новый регистр в определяемый тип ВладелецЗначенийКлючейДоступаНаборЗаписей или прописать логику его обработки в заимствованном общем модуле УправлениеДоступомПереопределяемый.

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

Таким образом, для решения проблемы с <Объект не найден> нужно не только использовать ВЫБРАТЬ РАЗРЕШЕННЫЕ, но и добавлять в запрос явное условие, которое инициирует проверку прав на связанные объекты. Это надежный способ формирования динамических списков, которые корректно отображают только разрешенные пользователю данные.