Как сформировать отчет в 1С в привилегированном режиме

Привилегированный режим в 1С отключает проверку прав доступа на уровне платформы: код внутри такого блока читает и изменяет любые данные информационной базы независимо от ролей текущего пользователя. Для отчетов это критично, когда пользователю с ограниченными правами нужно получить сводные данные по объектам, к которым у него нет прямого доступа — например, менеджеру вывести общую статистику по всем подразделениям, не открывая ему чужие документы.

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

Материал разбирает, где именно включается привилегированный режим при формировании отчета, какие есть способы (модуль объекта, общий модуль, безопасный режим), как проверить результат и каких ошибок избегать. Примеры приведены для управляемых форм и типового механизма БСП, но принципы одинаковы для любой конфигурации на платформе 8.3.

Что такое привилегированный режим и когда он нужен в отчетах

Привилегированный режим — это состояние исполнения кода, в котором платформа не выполняет проверку прав доступа к объектам метаданных и данным. Он включается программно вызовом УстановитьПривилегированныйРежим(Истина) либо автоматически — при выполнении кода в общем модуле с установленным свойством «Привилегированный».

Для отчетов привилегированный режим оправдан в трех типовых сценариях. Первый — сводная аналитика для широкого круга пользователей: руководителю отдела нужны итоги по компании, но роль не дает чтения всех регистров. Второй — регламентные отчеты, формируемые по расписанию от имени служебного пользователя с минимальными правами. Третий — отчеты, где в запросе фигурируют системные таблицы или данные обмена, доступ к которым обычно закрыт.

Важно понимать границу: привилегированный режим не заменяет проектирование ролей. Если пользователю по смыслу положено видеть данные — правильнее настроить роль и RLS, а не снимать проверку прав. Привилегированный режим уместен только там, где результатом является агрегированная или специально отфильтрованная выборка, а не прямой доступ к записям.

Способ 1: включение режима в модуле объекта отчета

Самый прямой путь — установить привилегированный режим в обработчике ПриКомпоновкеРезультата модуля объекта отчета. Этот обработчик вызывается на сервере при формировании отчета, и весь код внутри него выполняется в контексте текущего сеанса.

Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)

СтандартнаяОбработка = Ложь;

УстановитьПривилегированныйРежим(Истина);

КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных,
КомпоновщикНастроек.ПолучитьНастройки(), ДанныеРасшифровки);

ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, , ДанныеРасшифровки);

ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
ПроцессорВывода.УстановитьДокумент(ДокументРезультат);
ПроцессорВывода.Вывести(ПроцессорКомпоновки);

УстановитьПривилегированныйРежим(Ложь);

КонецПроцедуры

Обратите внимание на пару важных деталей. Во-первых, СтандартнаяОбработка = Ложь обязательна: иначе платформа сформирует отчет стандартным способом — уже без привилегированного режима. Во-вторых, отключение режима УстановитьПривилегированныйРежим(Ложь) должно выполняться даже при ошибке. Практичный прием — обернуть формирование в попытку и снимать режим в блоке исключения либо полагаться на то, что привилегированный режим автоматически сбрасывается при завершении серверного вызова.

У этого способа есть ограничение: он работает, только если отчет формируется программно через свой обработчик. Если используется стандартная форма отчета без переопределения ПриКомпоновкеРезультата, код модуля объекта не выполнится, и режим не включится.

УстановитьПривилегированныйРежим(Истина);
// ... формирование отчета ...
УстановитьПривилегированныйРежим(Ложь);

Способ 2: привилегированный общий модуль

Более управляемый вариант — вынести получение данных отчета в общий модуль с включенными свойствами «Сервер» и «Привилегированный». Весь код такого модуля выполняется в привилегированном режиме автоматически, без явного вызова УстановитьПривилегированныйРежим.

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

Преимущество подхода — централизованный контроль. Все обращения к закрытым данным сосредоточены в одном месте, их легко проверить при аудите и легко ограничить: модуль может принимать только параметры отбора и возвращать строго агрегированный результат, не давая вызывающему коду произвольный доступ к базе.

Способ 3: отчет через регламентное задание или COM-соединение

Если отчет формируется по расписанию, код регламентного задания выполняется на сервере в фоновом сеансе. Права проверяются для пользователя, от имени которого запущено задание, поэтому типовое решение — обернуть формирование в УстановитьПривилегированныйРежим(Истина) внутри процедуры обработчика задания.

Результат в этом случае обычно сохраняют в файл (MXL, Excel, PDF) или в присоединенные файлы справочника, а пользователи открывают уже готовый документ. Такой подход одновременно решает и проблему прав, и проблему производительности: тяжелый отчет строится ночью, а днем пользователи смотрят готовый результат.

При выгрузке результата во внешние системы через COM или HTTP-сервисы логика та же: привилегированный режим включается внутри серверного метода, который готовит данные. Ключевое правило — режим должен включаться как можно ближе к операции с данными и отключаться сразу после, а не охватывать весь сеанс обслуживания запроса.

Как проверить, что отчет сформировался корректно

Первая проверка — функциональная: запустите отчет под пользователем с ограниченными правами и убедитесь, что данные появились, а ошибок «Нарушение прав доступа» в журнале регистрации нет. Затем сравните итоги с эталоном: сформируйте тот же отчет под полными правами и сверьте контрольные суммы по ключевым группировкам.

Вторая проверка — безопасность. Убедитесь, что через расшифровку отчета пользователь не может «провалиться» в документы или записи регистров, к которым у него нет доступа. Если расшифровка открывает объект напрямую, стандартная проверка прав сработает при открытии формы, но если вы программно выводите детальные данные — проверку должен выполнять ваш код.

Третья проверка — состояние режима после выполнения. Если привилегированный режим не был отключен и серверный вызов продолжается дальше (например, идет запись данных), последующие операции тоже выполнятся без проверки прав. Признак проблемы — пользователь внезапно может выполнять действия, которые раньше были запрещены.

Типичные ошибки и риски

Самая частая ошибка — включить привилегированный режим на клиенте. Метод УстановитьПривилегированныйРежим доступен только в серверном контексте: на тонком и веб-клиенте вызов либо недоступен, либо не дает эффекта. Весь код, работающий с данными в привилегированном режиме, должен выполняться в серверных процедурах с директивой &НаСервере или в серверных общих модулях.

Вторая ошибка — слишком широкая область действия режима. Если включить привилегированный режим в начале большой процедуры, а отключить в конце, то любой код между этими точками, включая вызовы сторонних обработок, выполнится без проверки прав. Минимизируйте охват: включайте режим непосредственно перед запросом и выключайте сразу после получения результата.

Третья ошибка — возврат из привилегированного кода сырых данных. Если функция привилегированного модуля возвращает результат запроса с полным набором полей, вызывающий код получает фактически неограниченный доступ к закрытым данным. Возвращайте только те поля и строки, которые нужны отчету, лучше — уже сгруппированные.

Ограничения и альтернативы

Привилегированный режим — не единственный инструмент. Если проблема в том, что роль не дает доступа к нужным таблицам, рассмотрите настройку ролей с шаблонами ограничения доступа (RLS): пользователь получит чтение только разрешенных строк, и отчет сформируется штатно, без программных ухищрений.

Еще одна альтернатива — безопасный режим для внешних отчетов. Внешние отчеты по умолчанию выполняются в безопасном режиме, где привилегированный режим запрещен и УстановитьПривилегированныйРежим будет проигнорирован или вызовет ошибку. Если отчет подключается как внешний через механизм дополнительных отчетов БСП, нужно либо выдать профиль безопасности с разрешением на привилегированный режим, либо перенести логику в расширение конфигурации.

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

FAQ