Почему в отчете СКД возникает ошибка нарушения прав при группировке по полю Регистратор и как ее исправить?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При разработке отчетов на базе системы компоновки данных (СКД) разработчики периодически сталкиваются с парадоксальной ситуацией: если добавить в группировку конкретный реквизит регистратора (например, Регистратор.Комментарий), отчет формируется корректно, однако при попытке сгруппировать данные по самому полю Регистратор платформа 1С аварийно прерывает работу с ошибкой «Нарушение прав доступа». При этом расшифровка по документам может работать без сбоев, а у пользователя назначены базовые роли.

Разберем детально механизм возникновения этой коллизии и рассмотрим проверенные технические способы решения проблемы.

Анализ механизма возникновения ошибки

Для понимания причин такого поведения системы проанализируем структуру данных в 1С:

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

Выясним, почему же тогда успешно работает обращение через точку вида Регистратор.Комментарий. В этом сценарии платформа оптимизирует запрос: неявные соединения (LEFT JOIN) строятся только с теми таблицами документов, у которых действительно существует реквизит Комментарий. Если проблемный документ с ограничением RLS не содержит такого реквизита, он исключается из выборки. Кроме того, для скалярного поля не требуется строить строковое представление сложного составного типа, а при отсутствии прав на запись платформа возвращает значение NULL без фатальной ошибки.

Для точной диагностики первопричины в первую очередь обратимся к Журналу регистрации. В нем всегда фиксируется конкретный объект метаданных и право (как правило, чтение по определенному типу документа), к которому произошла неудачная попытка обращения.

Способ 1. Использование ключевого слова РАЗРЕШЕННЫЕ

Самый простой и быстрый способ устранить ошибку — заставить СКД игнорировать не разрешенные для текущего пользователя строки вместо генерации исключения. Перейдем в схему компоновки данных, откроем текст запроса в наборе данных и добавим инструкцию РАЗРЕШЕННЫЕ:


ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ОстаткиНоменклатуры.Номенклатура КАК Номенклатура,
    ОстаткиНоменклатуры.Регистратор КАК Регистратор,
    ОстаткиНоменклатуры.Количество КАК Количество
ИЗ
    РегистрНакопления.ОстаткиНоменклатуры КАК ОстаткиНоменклатуры

В этом случае платформа автоматически отфильтрует движения по тем типам документов, на чтение которых у пользователя установлены ограничения прав.

Способ 2. Ограничение типа данных через оператор ВЫРАЗИТЬ

Если специфика отчета предполагает вывод движений только определенных типов документов, мы можем явно подсказать платформе, к каким метаданным следует обращаться. Для этого применим оператор ВЫРАЗИТЬ в тексте запроса:


ВЫБРАТЬ
    Движения.Номенклатура КАК Номенклатура,
    ВЫРАЗИТЬ(Движения.Регистратор КАК Документ.РеализацияТоваровУслуг) КАК Регистратор,
    Движения.Сумма КАК Сумма
ИЗ
    РегистрНакопления.Продажи КАК Движения
ГДЕ
    Движения.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг

Благодаря явной типизации СКД построит соединение только с таблицей Документ.РеализацияТоваровУслуг, полностью исключив обращение ко всем остальным видам регистраторов составного типа.

Способ 3. Переопределение выражения представления в СКД

Когда нам требуется вывести ссылку на документ без вызова платформенного механизма автоматического получения представления по всем метаданным, настроим выражение представления вручную.

Разберем по шагам, как это сделать в конструкторе схемы компоновки данных:

  1. Откроем вкладку «Наборы данных».
  2. Найдем в списке доступных полей поле Регистратор.
  3. В колонке «Выражение представления» укажем собственную формулу формирования строки (например, склейку номера и даты или обращение к доступной функции общего модуля).

Пример выражения представления для поля:

Строка(Регистратор.Номер) + " от " + Формат(Регистратор.Дата, "ДФ=dd.MM.yyyy")

Такой подход снимает необходимость неявного обращения ко всем закрытым таблицам метаданных для построения стандартной строки представления ссылки.

Способ 4. Корректировка ограничений доступа (RLS)

Если пользователю необходимо видеть регистраторы в отчете, проанализируем настройки ролей в конфигурации:

  1. Разделение прав на «Чтение» и «Просмотр»: Ошибка в запросах всегда вызывается нехваткой права «Чтение» (или условием RLS на это право). Право «Просмотр» отвечает только за видимость в интерфейсе и интерактивное открытие форм. Убедимся, что право на чтение предоставлено.
  2. Ограничение RLS по полям: При настройке ограничений доступа на уровне записей рекомендуется накладывать условия не на весь документ целиком, а на ветку <Прочие поля>, оставляя системные поля Ссылка, Номер и Дата открытыми для чтения. В таком случае платформа сможет корректно строить представления регистраторов в любых отчетах без нарушения прав доступа.
← На главную