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