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