При настройке ограничений на уровне записей (RLS) в крупных корпоративных системах, таких как 1С:Управление холдингом или 1С:ERP, администраторы и разработчики часто сталкиваются с парадоксальной ситуацией. Несмотря на установленные запреты, пользователь продолжает видеть в динамических списках или журналах документов строки, где в колонке Организация отображается текст <Объект не найден...>. При этом сам документ не открывается, но наличие «фантомных» строк в списке путает сотрудников и создает угрозу утечки метаданных. Рассмотрим детально, почему так происходит и как полностью скрыть эти данные.
Первое, что мы должны понять: в системе 1С:Предприятие права доступа суммируются по принципу ИЛИ. Если пользователю назначено несколько ролей, и хотя бы одна из них разрешает чтение объекта без ограничений, то RLS в других ролях не сможет полностью скрыть этот объект. Ситуация с <Объект не найден...> возникает тогда, когда у пользователя есть право на Чтение (Read) ссылки объекта, но отсутствует право на Просмотр (View) его реквизитов, либо право на чтение ограничено лишь частично.
Проанализируем типичную ошибку настройки в конфигурации «Управление холдингом». В этой программе существует множество «технических» или сервисных ролей, которые необходимы для корректной работы различных подсистем (например, согласования или казначейства). Часто в таких ролях право на Чтение документа включено без шаблона RLS. Проверим список подозрительных ролей, которые могут давать «лишний» доступ:
ЧтениеЭкземпляровОтчетовДокументовУХ — часто используется в подсистеме отчетности и может не иметь ограничений по организациям.ЧтениеПриходныхКассовыхОрдеров или аналогичные роли для банковских документов.Для исправления ситуации нам необходимо убедиться, что во всех без исключения ролях, назначенных пользователю, для данного объекта метаданных прописан шаблон RLS на право Чтение. Если хотя бы в одной роли поле Ограничение доступа пустое — RLS работать не будет.
В современных версиях БСП (Библиотеки стандартных подсистем) используется так называемый «Производительный режим» RLS (Универсальное ограничение). В этом случае условия ограничения прописываются в модуле менеджера объекта. Рассмотрим пример настройки для документа ПоступлениеНаРасчетныйСчет.
Найдем в модуле менеджера процедуру ПриЗаполненииОграниченияДоступа и проверим её содержимое. Код должен выглядеть следующим образом:
Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
Ограничение.Текст =
"РазрешитьЧтениеИзменение
|ГДЕ
| ЗначениеРазрешено(Организация)";
КонецПроцедуры
Важно помнить, что после внесения изменений в этот код или при смене настроек в профилях групп доступа, система должна обновить вспомогательные данные. Проанализируем состояние регламентных заданий: если задание Заполнение данных для ограничения доступа еще выполняется или завершилось с ошибкой, изменения не вступят в силу. Проверить это можно в журнале регистрации или через консоль регламентных заданий.
Даже если мы идеально настроили RLS для самих документов, пользователи могут видеть «запрещенку» в отчетах. Это происходит потому, что отчеты в 1С чаще всего строятся на данных Регистров накопления или Регистров бухгалтерии. Если на сам документ наложено ограничение, а на регистр Хозрасчетный — нет, то в отчете (например, Оборотно-сальдовой ведомости) суммы будут видны, но вместо названия организации будет стоять всё то же <Объект не найден...>.
Выясним причину такого поведения: в типовых ролях разработчики часто забывают дублировать шаблоны RLS для связанных регистров. Разберем шаги по исправлению:
Чтение регистра добавим условие RLS по полю Организация.#ПоОрганизации("Организация").Чтобы не гадать, какая именно роль дает доступ, воспользуемся специализированными инструментами. Проанализируем возможности стандартного отчета «Анализ прав доступа» (находится в разделе Администрирование — Настройки пользователей и прав). В этом отчете можно увидеть сводную таблицу по всем ролям пользователя для конкретного объекта.
Если штатных средств недостаточно, рекомендуется использовать внешние обработки, например, «Редактор ограничения доступа» из состава Инструментов разработчика. Рассмотрим алгоритм проверки через консоль запросов:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Ссылка ИЗ Документ.ПоступлениеНаРасчетныйСчет.РАЗРЕШЕННЫЕ (хотя для динамических списков платформа обычно добавляет его автоматически).В некоторых случаях включение или отключение константы ОграничиватьДоступНаУровнеЭлементовУниверсально может временно «исправить» проблему, но это лишь следствие очистки кэша прав. При универсальном режиме система использует регистры сведений КлючиДоступаКОбъектам. Если данные в этих регистрах неактуальны (например, из-за аварийного завершения обновления ИБ), RLS будет работать непредсказуемо.
Посмотрим, как принудительно обновить эти данные. Для этого в коде (например, во внешней обработке) можно вызвать метод:
ПараметрыОбновления = Справочники.КлючиДоступа.ПараметрыОбновленияДоступа();
ПараметрыОбновления.СписокТипов = Новый Массив;
ПараметрыОбновления.СписокТипов.Добавить(Метаданные.Документы.ПоступлениеНаРасчетныйСчет);
Справочники.КлючиДоступа.ОбновитьДоступ(ПараметрыОбновления);
Подведем итог: для полного исчезновения записей <Объект не найден...> необходимо добиться ситуации, при которой ни одна роль пользователя не содержит безусловного права на чтение объекта, а все регистры, по которым строятся отчеты, также прикрыты соответствующими шаблонами RLS.