При внедрении механизма Row Level Security (RLS) в конфигурации «Управление торговлей 10.3» разработчики часто сталкиваются с неприятным визуальным эффектом: в списках документов вместо названий организаций, подразделений или складов пользователь видит системную заглушку «Объект не найден». Это происходит даже в тех случаях, когда сами документы пользователю доступны. Разберем детально, почему так происходит и как настроить систему, чтобы вместо ошибки отображалось понятное представление объекта, а доступ к его данным оставался ограниченным.
Для начала проанализируем ситуацию с точки зрения платформы 1С. Когда открывается список документов, например ЗаказПокупателя, система выполняет запрос к базе данных. В этом запросе есть поле Организация, которое является ссылкой на справочник Организации.
Ситуация «Объект не найден» возникает, когда выполняются два условия одновременно:
Платформа получает из базы GUID (уникальный идентификатор) ссылки, но при попытке получить строковое представление (наименование) для вывода на экран наталкивается на ограничение RLS. Поскольку доступ к записи запрещен полностью, платформа «скрывает» данные, подставляя текст «Объект не найден». Это стандартное поведение для защиты информации, но оно неудобно для работы, так как пользователь не понимает, к какому подразделению или организации относится документ, хотя сам документ видеть обязан.
Рассмотрим основной способ решения задачи — разделение прав на чтение разных реквизитов одного и того же объекта. Мы можем разрешить пользователю видеть «имя» объекта (представление), но запретить видеть всё остальное. В терминах RLS это называется разделением на «Все поля» и «Прочие поля».
Выполним следующие шаги в конфигураторе:
МенеджерПоПродажам).Организации или Подразделения).Правило №1: Доступ к представлению
Для полей Ссылка, Наименование, Код и ПометкаУдаления установим пустое ограничение или просто напишем ГДЕ ИСТИНА. Это позволит платформе всегда считывать название объекта для отображения в списках и отчетах.
Правило №2: Ограничение основных данных
Для состава полей «Прочие поля» пропишем реальное условие ограничения. Например, если мы ограничиваем доступ по группам доступа к контрагентам или организациям, запрос будет выглядеть примерно так:
ГДЕ Ссылка В (&СписокРазрешенныхОрганизаций)
ИЛИ Ссылка = Значение(Справочник.Организации.ПустаяСсылка)
В результате такой настройки в списке заказов пользователь увидит «Организация ООО "Ромашка"», но если он попытается открыть карточку этой организации, система либо выдаст ошибку доступа (так как «Прочие поля» закрыты), либо откроет пустую форму без реквизитов ИНН, КПП и расчетных счетов.
Проанализируем еще одну важную деталь. Если вы видите «Объект не найден» в списке документов, это часто означает, что на сам Документ ограничение не наложено, а на Справочник — наложено.
Рассмотрим правильную логику настройки:
Организация. Тогда лишние строки просто исчезнут из списка.Посмотрим на пример текста ограничения для роли документа в УТ 10.3. Часто в этой конфигурации используются стандартные шаблоны. Выясним, как применить шаблон #ПоОрганизациям правильно:
#ПоОрганизациям("Организация", "")
Если этот шаблон установлен в роли на право «Чтение», документы по запрещенным организациям просто не попадут в выборку, и проблема «Объект не найден» не возникнет, так как не будет самих строк с этими объектами.
Иногда требуется выводить документы, но вместо названия запрещенного объекта показывать фиксированную строку, например «[Доступ ограничен]». Рассмотрим, как это реализовать через язык запросов RLS. В условии чтения справочника можно использовать конструкцию ВЫБОР, хотя это более трудоемкий путь и требует аккуратности с производительностью.
Однако более эффективным методом в 1С 8.3 (на которой обычно запускают УТ 10.3) является настройка прав на чтение полей Дата, Номер и Ссылка. Если мы даем право на чтение этих полей без условий, а на все остальные поля — с условием, то в списках объект будет идентифицироваться корректно.
Важно помнить, что каждое условие RLS — это неявный JOIN или подзапрос, который платформа добавляет к каждому вашему запросу (в списках, отчетах, программном коде). Проанализируем, как не «положить» базу:
Организация, Подразделение, Склад), обязательно должны быть проиндексированы в метаданных.ГДЕ Ссылка.Владелец.ОсновнойМенеджер = &ТекущийПользователь). Лучше использовать параметры сеанса.ПараметрыСеанса.ДоступныеОрганизации (тип ФиксированныйМассив). Это значительно ускорит работу.Подведем итог. Чтобы избавиться от «Объект не найден», мы должны четко решить: должны ли документы быть видны? Если нет — настраиваем RLS на документ. Если да — настраиваем RLS на справочник, разделяя доступ: разрешаем чтение идентификационных полей (Ссылка, Наименование) для всех, и ограничиваем «Прочие поля» только для разрешенных записей. Этот метод позволяет сохранить целостность интерфейса и обеспечить требуемый уровень безопасности данных в «1С:Управление торговлей 10.3».