Мы часто сталкиваемся с ситуациями, когда поведение отчета под полными правами и под правами обычного пользователя различается. Однако случай, когда данные физически доступны (запрос их возвращает), но система компоновки данных (СКД) упорно помечает поле как «Поле не найдено» или убирает возможность группировки, требует глубокого понимания механики прав доступа в платформе 1С:Предприятие. Давайте подробно разберем эту проблему, проанализируем причины и найдем эффективные способы решения.
Рассмотрим типичный сценарий. Разработан отчет по справочнику (например, Справочник.ТранспортныеСредства). В отчете настроена группировка по самому элементу справочника (ссылке) с иерархией. У администратора отчет формируется корректно.
Однако у пользователя с ограниченными правами наблюдается следующая картина:
ТС.ГосНомер, ТС.VIN), выводятся корректно.Такое поведение указывает на то, что проблема лежит не в плоскости выборки данных (RLS на чтение записей), а в плоскости представления данных или прав на просмотр полей.
Прежде чем углубляться в конфигуратор, мы должны исключить самый банальный вариант — "залипший" кэш настроек пользователя. СКД сохраняет структуру доступных полей в пользовательских настройках. Если права изменились, а настройка осталась старой, поле может быть помечено как недоступное.
Нам необходимо выполнить полную очистку. Стандартного сброса настроек в форме отчета может быть недостаточно. Выполним следующие действия:
Также полезно проверить наличие сохраненных вариантов отчета через меню Все функции (или Функции для технического специалиста) -> Справочники -> Варианты отчетов / Пользовательские настройки отчетов. Если там есть записи, относящиеся к нашему пользователю и отчету, пометим их на удаление и удалим.
Если после полной очистки проблема сохраняется, значит, дело в правах доступа.
Давайте проанализируем разницу между правами. В ролях 1С есть два ключевых права для каждого объекта метаданных: Чтение и Просмотр.
Система компоновки данных работает на стыке этих прав. Она проверяет доступность полей для вывода пользователю. Если у роли пользователя установлено право Чтение, но снято право Просмотр для справочника ТранспортныеСредства, мы получим именно описанную ситуацию: запрос данные вернет, но СКД скроет поле-ссылку из доступных полей, чтобы пользователь не мог "увидеть" объект в интерфейсе.
Решение: Зайдем в конфигуратор, откроем роль пользователя и проверим наличие галочки Просмотр для всего справочника.
Ситуация может быть сложнее. Допустим, права на сам справочник полные. Но СКД анализирует права доступа к конкретным полям. Особое внимание следует уделить стандартным реквизитам.
Для корректного отображения ссылочного поля в группировке СКД пользователю необходимы права на просмотр следующих стандартных реквизитов:
Ссылка (Ref)ПометкаУдаления (DeletionMark) — часто используется для условного оформления.Код и Наименование.Если в настройках прав доступа к реквизитам (кнопка Права доступа к реквизитам в окне редактирования роли) у пользователя отключен просмотр поля, которое является Основным представлением справочника (обычно это Наименование), платформа может скрыть и саму ссылку, так как не сможет сформировать человекочитаемое представление объекта.
Проверим это в конфигураторе: убедимся, что на стандартные реквизиты установлены права Просмотр.
Это одна из самых частых причин "исчезновения" группировок. Если в роли настроен RLS (Record Level Security), который ограничивает доступ к полю Ссылка, СКД может вести себя перестраховочно.
Представим, что у нас есть шаблон RLS:
#ПоЗначениям("Справочник.ТранспортныеСредства", "", "",
"Организация", "Организация", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","")
При построении отчета СКД пытается построить иерархию или получить представление ссылок. Если механизм RLS блокирует чтение некоторых записей на уровне ссылочной целостности, платформа может исключить поле из доступных группировок, чтобы избежать ошибок выполнения запроса или отображения <Объект не найден>.
Диагностика: Попробуем временно дать пользователю роль без RLS (но не Полные права). Если поле появится — проблема в тексте ограничения доступа. Возможно, стоит переписать запрос RLS, используя конструкцию РАЗРЕШЕННЫЕ (хотя СКД обычно подставляет её сама) или проверить корректность параметров сеанса, используемых в шаблонах.
Еще один "невидимый" враг — Функциональные опции (ФО). Справочники и реквизиты в конфигурации могут быть привязаны к ФО. Если функциональная опция выключена для конкретного пользователя (например, зависит от настройки программы, к которой у пользователя нет доступа, или от параметра сеанса), то связанные с ней поля полностью исчезают из интерфейса, включая настройки отчетов СКД.
Давайте проверим:
Если права настроены корректно, RLS проверен, а поле все равно недоступно (что бывает при сложных багах платформы или специфичных настройках профилей безопасности), существует проверенный способ решения, который помог автору проблемы.
Мы можем изменить схему компоновки данных, явно разделив получение данных.
Как это сделать:
ТранспортныеСредства (выберем Ссылку, Наименование и нужные реквизиты).Почему это работает?
Когда мы используем один запрос, СКД строит сложный итоговый SQL-запрос, накладывая ограничения прав доступа на все таблицы сразу. Иногда "жесткие" права на одну из связанных таблиц могут заблокировать видимость поля. Разделяя наборы данных, мы заставляем платформу выполнять выборку справочника отдельным подзапросом. В этом контексте проверка прав происходит изолированно для справочника, и если у пользователя есть права на него, поле успешно выводится и становится доступным для группировки.
Итак, если вы столкнулись с пропажей группировки в отчете, выполните действия в следующем порядке:
Просмотр на справочник и на его стандартные реквизиты (Ссылка, Код, Наименование).