Как правильно настроить RLS для чтения регистра накопления по организации-владельцу склада

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

Проанализируем причины такого поведения платформы 1С:Предприятие и разберем по шагам, как корректно ограничить доступ к данным и скрыть остатки по чужим складам и организациям.

Выясним причину появления строк <Объект не найден>

Подобное поведение возникает из-за раздельной обработки прав RLS на уровне справочников и регистров накопления:

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

Способ 1. Настройка шаблона RLS на справочнике Склады

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

Для роли пользователя на право Чтение справочника Склады зададим условие с использованием стандартного шаблона:

#ТаблицаОсновогоВидаОбъектаДоступа("Организации", "Владелец", "")

Разберем параметры данного шаблона:

1. Первый параметр ("Организации") — наименование вида объекта доступа, по которому настраиваются права в профилях пользователей.
2. Второй параметр ("Владелец") — имя реквизита справочника, в котором хранится ссылка на организацию-владельца.
3. Третий параметр — дополнительные условия или пустая строка, если фильтрация выполняется строго по реквизиту.

Способ 2. Ограничение регистра накопления через подзапрос к разрешенным складам

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

ГДЕ Склад В
    (ВЫБРАТЬ
        ТаблицаСкладов.Ссылка
    ИЗ
        Справочник.Склады КАК ТаблицаСкладов)

Посмотрим, как это работает на практике: при обращении к регистру ТоварыНаСкладах платформа выполняет подзапрос к справочнику Склады. Так как на справочник уже наложен RLS, подзапрос вернет только доступные текущему пользователю склады. Все записи по остальным складам будут автоматически отфильтрованы на уровне СУБД, и строки с <Объект не найден> перестанут попадать в отчет.

Способ 3. Использование профильного регистра ТоварыОрганизаций

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

1. Регистр ТоварыНаСкладах предназначен для количественного учета по местам хранения без привязки к организациям.
2. Регистр ТоварыОрганизаций содержит прямое измерение Организация.

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

Важные правила при отладке RLS

При проверке настроек ограничений обратим внимание на следующие ключевые нюансы:

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