Как программно провести документ в 1С при ошибке «Редактирование документов пользователя запрещено»?

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

Однако стандартная попытка использовать метод УстановитьПривилегированныйРежим(Истина) в коде часто оборачивается неудачей: система все равно аварийно завершает работу и выдает ошибку вида «Редактирование документов пользователя [ИмяПользователя] запрещено». В этой статье мы подробно разберем, почему возникает эта проблема, как устроена эта проверка изнутри и какими способами можно ее корректно обойти.

Почему не работает привилегированный режим?

Для начала проанализируем архитектуру разграничения прав в платформе 1С:Предприятие и прикладных решениях. Привилегированный режим — это встроенный платформенный механизм, который временно отключает проверку прав доступа на уровне базы данных (так называемый RLS — Row Level Security) и ограничения ролей, заданные в конфигураторе.

Однако ошибка «Редактирование документов пользователя...» имеет совершенно иную природу:

1. Это прикладное (программное) ограничение, написанное разработчиками конкретной конфигурации (особенно часто оно встречается в локализованных решениях для Казахстана, таких как «Бухгалтерия для Казахстана», «1С-Рейтинг: КУФИБ» и др.).
2. В модуле объекта документа (или в общей подписке на событие ПередЗаписью) вызывается процедура общего модуля проверки прав.
3. Этот программный код считывает значение из ПараметрыСеанса.ТекущийПользователь и сравнивает его с реквизитом Автор (или Ответственный) записываемого документа.
4. Если текущий пользователь не совпадает с автором документа и у него нет административных прав, прикладной код принудительно устанавливает параметр Отказ = Истина и выводит предупреждение.

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

Ниже мы рассмотрим три эффективных способа решения этой проблемы: от простой административной настройки до гибких программных методов.

---

Способ 1. Административное делегирование прав (Без изменения кода)

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

Выполним настройку по шагам:

1. Перейдем в раздел Администрирование, далее выберем пункт Настройки пользователей и прав и откроем справочник Пользователи.
2. Найдем в списке пользователя (например, согласующего сотрудника), под которым запускается обработка, и откроем его карточку.
3. На панели навигации карточки пользователя перейдем по ссылке Права доступа к документам других пользователей.
4. В открывшейся форме добавим новую запись:
   • В поле Пользователь укажем нашего согласующего (того, кто запускает обработку).
   • В поле Объект редактирования (Пользователь) выберем автора документа (инициатора согласования), чьи документы система должна разрешить изменять.
5. Сохраним настройки и попросим пользователя перезапустить сеанс 1С.

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

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

---

Способ 2. Использование механизма дополнительных свойств

Если нам необходимо обойти проверку прав программно и только при записи из конкретной обработки, наиболее элегантным решением будет использование встроенной структуры ДополнительныеСвойства объекта.

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

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

Шаг 1. В коде нашей обработки, которая вносит изменения в документ и проводит его, добавим в дополнительные свойства уникальный маркер-флаг:

// Получаем объект документа для изменения
ДокументОбъект = СсылкаНаДокумент.ПолучитьОбъект();

// Заполняем необходимые реквизиты, пришедшие с рабочего стола согласования
ДокументОбъект.СтатусСогласования = Перечисления.СтатусыСогласования.Согласован;

// Записываем специальный признак в дополнительные свойства
ДокументОбъект.ДополнительныеСвойства.Вставить("ОбходПроверкиПравПриСогласовании", Истина);

// Проводим документ под привилегированным режимом (если это необходимо для платформенных прав)
УстановитьПривилегированныйРежим(Истина);
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
УстановитьПривилегированныйРежим(Флоу);

Шаг 2. Теперь нам нужно перехватить этот флаг в модуле объекта документа. Перейдем в модуль нужного документа и найдем обработчик события ПередЗаписью. Нам необходимо обернуть стандартную процедуру проверки прав в условие:

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
	
	// Проверяем, передан ли наш секретный ключ в дополнительные свойства
	ПропускатьПроверку = Ложь;
	Если ДополнительныеСвойства.Свойство("ОбходПроверкиПравПриСогласовании") Тогда
		ПропускатьПроверку = ДополнительныеСвойства.ОбходПроверкиПравПриСогласовании;
	КонецЕсли;
	
	Если Не ПропускатьПроверку Тогда
		// Здесь вызывается стандартная проверка прав из общего модуля конфигурации
		// Например: ПраваДоступаКОбъектам.ПроверитьПравоРедактированияДокументов(ЭтотОбъект, Отказ);
	КонецЕсли;

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

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

---

Способ 3. Реализация обхода через расширение конфигурации

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

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

Разберем по шагам создание расширения:

1. Создадим новое расширение конфигурации в дереве метаданных.
2. Добавим в расширение общий модуль, отвечающий за проверку прав (например, ПраваДоступаКОбъектам).
3. Применим к целевой процедуре аннотацию &Вместо, переопределив ее поведение.

Посмотрим на пример кода, который будет выполняться в общем модуле расширения:

&Вместо("ПроверитьПравоРедактированияДокументов")
Процедура Расш_ПроверитьПравоРедактированияДокументов(ДокументОбъект, Отказ)
	
	// Проверяем наличие нашего уникального свойства обхода проверки
	Если ДокументОбъект.ДополнительныеСвойства.Свойство("ОбходПроверкиПравПриСогласовании") 
		И ДокументОбъект.ДополнительныеСвойства.ОбходПроверкиПравПриСогласовании = Истина Тогда
		
		// Если флаг установлен программно, просто прерываем проверку и разрешаем запись
		Возврат;
		
	КонецЕсли;
	
	// В остальных случаях вызываем оригинальный метод типовой конфигурации
	ПродолжитьВызов(ДокументОбъект, Отказ);
	
КонецПроцедуры

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

---

Важное замечание о выполнении кода на сервере

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

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

Соблюдение этих правил и использование механизма ДополнительныеСвойства позволит вам гибко управлять логикой проведения документов, сохраняя баланс между требованиями безопасности и удобством пользователей.