Как провести документ в привилегированном режиме и программно изменить реквизиты справочника в 1С?

Часто в практике разработки на 1С возникает задача: при проведении определенного документа необходимо программно изменить данные в другом объекте, например, обновить реквизиты в справочнике Номенклатура. Однако у пользователя, который проводит документ, может не быть роли, разрешающей изменение этого справочника. Система закономерно выдает ошибку «Отказ в доступе». Рассмотрим подробнее, как обойти эту ситуацию без прямого расширения пользовательских прав, и проанализируем, почему стандартный метод может не срабатывать.

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

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

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

Решение 1: Вынос логики в привилегированный Общий модуль

Разберем по шагам наиболее правильный и безопасный метод, соответствующий стандартам разработки 1С. Согласно проверкам автоматических анализаторов кода (например, BSL Language Server или SonarQube), безусловный вызов повышения прав в модуле документа считается уязвимостью. Чтобы сделать все чисто, воспользуемся общими модулями.

Создадим новый Общий модуль, назовем его, например, ОбработкаСправочниковПривилегированный. В свойствах этого модуля (в палитре свойств конфигуратора) обязательно установим флажок Привилегированный. В этом модуле сервер всегда будет работать с полными правами, игнорируя ролевые ограничения.

Перенесем туда логику модификации номенклатуры:

Процедура ОбновитьРеквизитыНоменклатуры(СсылкаНаДокумент) Экспорт
    
    // В этом модуле проверки прав отключены автоматически
    // Пишем логику изменения реквизитов справочника Номенклатура
    
КонецПроцедуры

А в самом модуле документа, в процедуре ОбработкаПроведения, мы просто вызовем нашу функцию:

Процедура ОбработкаПроведения(Отказ, Режим)
    
    // Основная логика проведения (движения по регистрам и т.д.)
    // ...
    
    // Вызов привилегированного кода для изменения справочника
    ОбработкаСправочниковПривилегированный.ОбновитьРеквизитыНоменклатуры(ЭтотОбъект.Ссылка);
    
КонецПроцедуры

Решение 2: Использование свойства метаданных "Прив. режим при проведении"

Посмотрим на альтернативный способ. Платформа 1С позволяет управлять правами при проведении на уровне метаданных. Откроем палитру свойств самого объекта «Документ». Там можно найти флажок Прив. режим при проведении.

При установке этого флага вся процедура проведения автоматически запускается платформой в привилегированном режиме. Дополнительно писать код не нужно. Однако проанализируем ситуацию и возможные риски:

1. Вы автоматически переводите ВСЕ документы данного типа в этот режим, полностью отключая проверки прав для всех пользователей, которые могут инициировать проведение.
2. Отключение RLS: Привилегированный режим отключает не только проверку ролей, но и ограничения на уровне записей (RLS). Это может привести к тому, что документ затронет данные закрытых организаций или подразделений, которые пользователь вообще не должен был видеть.

Этот способ можно использовать, но с большой осторожностью, понимая, что безопасность системы снижается.

Особенности ручного управления привилегированным режимом

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

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

Альтернативные объекты конфигурации

Стоит отметить, что автоматическое повышение прав через свойства доступно не только для документов. Настроить подобное поведение можно и для других объектов. Например, у Бизнес-процессов есть свойство Привилегированный режим при создании задач, а у функциональных опций — Привилегированный режим при получении. Знание этих свойств поможет более гибко управлять правами в сложных системах.