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