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