В процессе работы с информационными системами на платформе 1С:Предприятие, особенно при использовании механизма ограничения доступа на уровне записей (RLS), мы можем столкнуться с ситуацией, когда данные, которые должны быть полностью скрыты от пользователя, отображаются в виде "<Объект не найден>". Это особенно часто проявляется, когда RLS настроен на ссылочные объекты, но не всегда корректно исключает записи, ссылающиеся на эти недоступные объекты.
В этой статье мы подробно разберем проблему, когда в конфигурации 1С:УНФ регистр накопления "Продажи" при включенном RLS не фильтрует записи по организации полностью, а вместо этого показывает сообщение "<Объект не найден>" для тех организаций, к которым у пользователя нет доступа. Мы проанализируем причины такого поведения и рассмотрим эффективные методы диагностики и решения данной проблемы.
Давайте рассмотрим исходную ситуацию. У нас есть база данных с пятью организациями, но пользователю разрешен доступ только к двум из них. Когда пользователь открывает список регистра накопления "Продажи" по прямой ссылке e1cib/list/РегистрНакопления.Продажи и включает группировку по организациям, он видит три организации, отображаемые как "<Объект не найден>", а также движения по ним. При этом, если пользователь заходит в список справочника "Организации" по ссылке e1cib/list/Справочник.Организации, он видит только две разрешенные организации.
Суть проблемы: сообщение "<Объект не найден>" в поле "Организация" регистра обычно возникает, когда ограничение доступа (RLS) установлено на сам ссылочный объект – в нашем случае, на справочник "Организации". Это ограничение успешно скрывает сам объект-ссылку. Однако, если RLS на основном объекте (регистре накопления "Продажи") не настроен таким образом, чтобы полностью исключать записи, ссылающиеся на недоступные организации, то платформа все равно вернет эти записи регистра, но не сможет отобразить информацию о связанных с ними организациях, к которым у пользователя нет прав чтения. В результате мы видим пустые ссылки или сообщения "<Объект не найден>".
Это не является ошибкой RLS как такового, а скорее результатом того, как платформа 1С обрабатывает отображение ссылок на объекты, к которым у пользователя нет прав чтения. Критически важно понимать, что сама запись регистра при этом видна пользователю, что может нарушать принципы конфиденциальности и разграничения доступа, если по косвенным признакам (например, по сумме или количеству) можно определить информацию о продажах недоступной организации.
Многие разработчики ошибочно полагают, что при прямом открытии объекта по ссылке e1cib/list/РегистрНакопления.Продажи не используются динамические списки. На самом деле, даже в этом случае платформа 1С генерирует неявный динамический список. К запросам, формирующим данные для таких динамических списков, автоматически добавляются условия RLS, если они настроены для таблиц, участвующих в запросе. Это фундаментальный принцип работы платформы, и мы всегда должны учитывать его при отладке RLS.
Таким образом, наша задача заключается в том, чтобы RLS для регистра накопления "Продажи" был настроен настолько строго, чтобы он не просто скрывал ссылку на организацию, но и полностью исключал из выборки все записи регистра, которые относятся к недоступным организациям.
В предоставленной информации мы видим, что доступ к регистру "Продажи" регулируется ролями с включенным RLS. Вот пример RLS, который использует автор:
#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляРегистра("ИдентификаторыОбъектовМетаданных.РегистрНакопленияПродажи", "Контрагент", "Организация", "", "", "")
#Иначе
#ПоЗначениям( "РегистрНакопления.Продажи", "Чтение", "",
"Организации","Организация",
"ГруппыКонтрагентов","Контрагент",
"","","","","","","","","","","","","","","","","","","","","","","","","","","","")
#КонецЕсли
Давайте разберем этот шаблон RLS подробнее:
#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда указывает на использование универсального механизма RLS, который обычно применяется в типовых конфигурациях на БСП. В этом случае используется шаблон #ДляРегистра.#Иначе активируется, если универсальный механизм отключен, и в ней используется шаблон #ПоЗначениям. Этот шаблон предназначен для более детальной настройки ограничения доступа по значениям полей.Нас интересует именно шаблон #ПоЗначениям, так как он более специфичен и часто используется для установки детальных ограничений. Его синтаксис таков:
#ПоЗначениям( "ИмяТаблицы", "ВидДоступа", "ИмяГруппыДоступа", "ИмяПараметра1","ПолеТаблицы1", ..., "ИмяПараметраN","ПолеТаблицыN" )
В нашем случае:
"РегистрНакопления.Продажи": Таблица, к которой применяется ограничение."Чтение": Вид доступа (чтение)."": Имя группы доступа (не используется)."Организации","Организация": Это ключевая пара. Она означает, что доступ к записям регистра будет ограничен по полю Организация регистра, сравнивая его со значениями, разрешенными в параметре Организации. Этот параметр обычно заполняется списком организаций, к которым у пользователя есть доступ."ГруппыКонтрагентов","Контрагент": Аналогично, ограничение по полю Контрагент.Проблема, вероятно, кроется в том, как этот шаблон #ПоЗначениям взаимодействует с общим механизмом ограничения доступа. Возможно, он корректно скрывает сами объекты организаций, но не создает достаточно строгого условия в запросе, чтобы полностью исключить строки регистра, ссылающиеся на недоступные организации. Или, что более вероятно, имеется нюанс в конфигурации ролей или параметрах доступа, который не позволяет RLS полноценно отработать.
Когда мы сталкиваемся с подобными сложностями в работе RLS, особенно в конфигурациях, разработанных на основе Библиотеки стандартных подсистем (БСП), одним из самых мощных и незаменимых инструментов для диагностики является обработка "ПроверкаВнедренияБСП".
Эта обработка не просто проверяет общую корректность внедрения БСП, но и содержит специализированные проверки для подсистемы "Управление доступом", которая напрямую отвечает за работу RLS. Разработчики БСП предусмотрели в ней механизмы для анализа настроек доступа, шаблонов ограничений и потенциальных ошибок или неоптимальных решений, которые могли быть допущены при конфигурировании RLS.
Именно эти рекомендации могут дать нам четкое указание на то, где именно кроется проблема с неполной фильтрацией регистра "Продажи".
Использование этой обработки значительно сокращает время на поиск неисправностей, поскольку она автоматизирует многие шаги по анализу сложной системы RLS.
Если обработка "ПроверкаВнедренияБСП" не дает исчерпывающих результатов или мы хотим углубиться в детали, рассмотрим другие методы:
В производительном режиме работы RLS права доступа рассчитываются предварительно и сохраняются в специальных регистрах сведений (например, РегистрСведений.КлючиДоступа, РегистрСведений.КлючиДоступаКОбъектам). После любых изменений в настройках RLS (изменение ролей, профилей групп доступа, состава групп доступа или самих шаблонов RLS) критически важно выполнить процедуру обновления доступа на уровне записей. В 1С:УНФ и других конфигурациях на БСП это делается через раздел "Администрирование" -> "Настройка пользователей и прав" -> "Обновление доступа на уровне записей". Ошибки в ходе этой процедуры могут указывать на проблемы в ограничениях или некорректно заданные параметры.
Для глубокой отладки RLS мы можем использовать технологический журнал 1С:Предприятия. Он позволяет увидеть реальные запросы к базе данных (SQL-запросы), которые формирует платформа с учетом RLS. Анализируя записи технологического журнала с событиями, связанными с доступом (например, DBMSSQL, DB2, SDBL), мы можем понять, какие именно условия RLS были добавлены в запрос к регистру "Продажи" и почему данные не скрываются полностью. Это позволит нам точно определить, где именно "не дотягивает" фильтрация.
Давайте еще раз внимательно проанализируем текст шаблона RLS для регистра накопления "Продажи" и для справочника "Организации" в ролях пользователя. Убедитесь, что логика ограничения доступа явно предписывает не только скрывать ссылку на организацию, но и не возвращать записи регистра, относящиеся к ней.
В случае с #ПоЗначениям("РегистрНакопления.Продажи", "Чтение", "", "Организации","Организация"), платформа попытается создать условие вида ГДЕ РегистрНакопленияПродажи.Организация В (&Организации). Мы должны убедиться, что список &Организации действительно содержит только разрешенные организации и что нет других условий RLS или настроек, которые могли бы отменить это ограничение или добавить в выборку записи с недоступными организациями.
Иногда требуется более сложная логика в RLS, например, создание временных таблиц с разрешенными объектами и последующее соединение с ними в запросе основного списка для полного исключения неразрешенных объектов. Однако в типовых конфигурациях на БСП обычно достаточно корректно настроенных шаблонов RLS.
Убедитесь, что у пользователя нет избыточных прав, которые могут обходить RLS. Например, роли, дающие полное чтение всех данных, или роли, которые предоставляют доступ к объектам, связанным с организациями, но без RLS. Проверьте также права на регистры сведений, в которых хранятся параметры RLS (например, РегистрСведений.НастройкиПравДоступа, РегистрСведений.ОбъектыДоступа).
Проблема неполной фильтрации данных RLS, проявляющаяся как "<Объект не найден>", является серьезной, так как может привести к утечке конфиденциальной информации. Ее решение требует системного подхода и глубокого понимания механизма ограничения доступа в 1С.
Мы выяснили, что основной причиной является недостаточно строгое условие RLS на уровне основного объекта (регистра), которое не исключает записи целиком, а лишь скрывает ссылки на недоступные объекты. Для диагностики таких проблем в типовых конфигурациях на БСП настоятельно рекомендуем использовать обработку "ПроверкаВнедренияБСП". Этот инструмент, созданный разработчиками платформы, является нашим надежным помощником в анализе и устранении ошибок RLS.
Помимо "ПроверкаВнедренияБСП", мы должны помнить о важности регулярного обновления ключей доступа, умении работать с технологическим журналом и внимательном анализе самих шаблонов RLS и их взаимодействия. Только комплексный подход позволит нам обеспечить полную конфиденциальность данных и корректное функционирование системы ограничения доступа на уровне записей.