В процессе сопровождения и администрирования баз данных «1С:Предприятие» перед разработчиками нередко встает задача ограничить несанкционированные или случайные действия пользователей. Одной из таких критических операций является отмена проведения документов (распроведение). Например, когда менеджер случайно или намеренно распроводит документ реализации прошлого периода, это может привести к нарушению последовательности партионного учета, искажению взаиморасчетов и проблемам со сдачей отчетности.
В этой статье мы подробно разберем, как технически реализовать проверку при отмене проведения документа. Мы проанализируем различные подходы — от быстрого программного перехвата до кошерного разграничения прав доступа, а также разберем, как обойти проблему модальности в управляемом приложении при запросе пароля.
Первый вопрос, который возникает у начинающих разработчиков: «Существует ли в платформе специализированное событие вроде ПередОтменойПроведения?». Ответ — нет, отдельного предопределенного события для отмены проведения в модулях документов не предусмотрено.
Дело в том, что в платформе «1С:Предприятие» отмена проведения — это частный случай записи документа. Когда пользователь нажимает кнопку «Отменить проведение», система выполняет запись объекта со специальным режимом. Следовательно, перехватывать это действие нужно в стандартном обработчике ПередЗаписью.
При этом важно понимать, что документ может быть записан в различных режимах. Для точного определения отмены проведения нам необходимо анализировать параметр РежимЗаписи, который передается в обработчик. Нам интересен системный перечислитель РежимЗаписиДокумента.ОтменаПроведения.
Если в вашей конфигурации много документов, для которых нужно внедрить подобную проверку, писать код в модуле каждого документа — неэффективно. Лучшим решением будет создание универсальной Подписки на событие. Это позволит избежать изменения типовых объектов конфигурации и упростит дальнейшие обновления системы.
Разберем по шагам, как настроить подписку на событие для проверки прав или пароля при отмене проведения:
ПроверитьПравоОтменыПроведенияПередЗаписью.ДокументОбъект.РеализацияТоваровУслуг, ДокументОбъект.ЗаказПокупателя и т.д.).ПередЗаписью.Рассмотрим пример кода, который необходимо написать в созданном общем модуле:
Процедура ПроверитьПравоОтменыПроведенияПередЗаписьюПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
// Проверяем, что происходит именно отмена проведения
Если РежимЗаписи = РежимЗаписиДокумента.ОтменаПроведения Тогда
// Способ 1: Проверка доступности специальной роли
Если Не РольДоступна("РазрешитьОтменуПроведения") Тогда
Отказ = Истина;
ВызватьИсключение "У вас нет достаточных прав для отмены проведения этого документа! Обратитесь к администратору.";
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Важное замечание: Использование функции РольДоступна() в современных конфигурациях считается устаревшим подходом. Если вы работаете в системе, использующей Библиотеку Стандартных Подсистем (БСП), более кошерным решением будет использование функции ПравоДоступа() или проверка ролей через механизмы БСП.
Иногда бизнес-требования диктуют необходимость именно интерактивного ввода пароля прямо перед выполнением операции. В современных управляемых формах 1С (начиная с платформы 8.3) режим модальности по умолчанию отключен. Это означает, что мы не можем просто приостановить выполнение кода на сервере, показать окно ввода пароля и дождаться ответа.
Для реализации этой логики нам потребуется использовать асинхронный подход с использованием объекта ОписаниеОповещения. Давайте разберем этот алгоритм.
Основная идея заключается в следующем: мы перехватываем запись на клиенте в форме документа, отменяем стандартную запись, запрашиваем пароль через немодальное окно, и в случае успеха повторно вызываем запись, передавая специальный транзитный признак («пароль проверен») на сервер.
Посмотрим на практическую реализацию в модуле управляемой формы документа:
&НаКлиенте
Перем ПарольПроверен; // Локальная переменная модуля формы
&НаКлиенте
Процедура ПередЗаписью(Отказ, ПараметрыЗаписи)
// Если это не отмена проведения, пропускаем проверку
Если ПараметрыЗаписи.РежимЗаписи <> РежимЗаписиДокумента.ОтменаПроведения Тогда
Возврат;
КонецЕсли;
// Если пароль уже был успешно проверен на этом шаге, разрешаем запись
Если ПарольПроверен = Истина Тогда
ПарольПроверен = Ложь; // Сбрасываем флаг для последующих вызовов
Возврат;
КонецЕсли;
// Иначе отменяем стандартную запись и запрашиваем пароль
Отказ = Истина;
ПараметрыОповещения = Новый Структура;
ПараметрыОповещения.Вставить("ПараметрыЗаписи", ПараметрыЗаписи);
Оповещение = Новый ОписаниеОповещения("ПослеВводаПароля", ЭтотОбъект, ПараметрыОповещения);
ПоказатьВводЗначения(Оповещение, "", "Введите пароль для отмены проведения документа:", Тип("Строка"));
КонецПроцедуры
&НаКлиенте
Процедура ПослеВводаПароля(ВведенноеЗначение, ДополнительныеПараметры) Экспорт
Если ВведенноеЗначение = Неопределено Тогда
// Пользователь отказался от ввода или закрыл окно
Возврат;
КонецЕсли;
// Проверяем введенный пароль на клиенте (или передаем на сервер для проверки)
Если ВведенноеЗначение = "СекретныйПароль123" Тогда
ПарольПроверен = Истина;
// Повторно инициируем запись документа с сохраненными параметрами
Записать(ДополнительныеПараметры.ПараметрыЗаписи);
Иначе
ПоказатьПредупреждение(, "Неверный пароль! Операция отмены проведения отклонена.");
КонецЕсли;
КонецПроцедуры
Описанный выше клиентский метод имеет один существенный недостаток: он защищает отмену проведения только при действиях пользователя в конкретной форме документа. Если отмена проведения будет вызвана программно (например, через групповую обработку документов, внешнюю обработку или обмен данными), то клиентский код формы просто не отработает, и документ будет успешно распроведен в обход правил безопасности.
Для надежной защиты необходимо связать клиентскую проверку с серверной транзакцией. Для этого используется механизм временного хранения параметров в свойстве объекта ДополнительныеСвойства.
Модифицируем наш код. В форме документа при успешном вводе пароля мы помещаем признак успешной проверки в объект документа перед записью:
&НаКлиенте
Процедура ПослеВводаПароля(ВведенноеЗначение, ДополнительныеПараметры) Экспорт
Если ВведенноеЗначение = "СекретныйПароль123" Тогда
ПарольПроверен = Истина;
// Модифицируем объект перед повторной записью
ЭтотОбъект.ДополнительныеСвойства.Вставить("ПарольУспешноВведен", Истина);
Записать(ДополнительныеПараметры.ПараметрыЗаписи);
Иначе
ПоказатьПредупреждение(, "Неверный пароль!");
КонецЕсли;
КонецПроцедуры
Теперь на сервере в модуле объекта документа (или в подписке на событие ПередЗаписью) мы выполняем жесткую проверку этого признака:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если РежимЗаписи = РежимЗаписиДокумента.ОтменаПроведения Тогда
// Проверяем, пришел ли флаг успешной проверки с клиента
ПарольПроверенНаКлиенте = Ложь;
ЭтотОбъект.ДополнительныеСвойства.Свойство("ПарольУспешноВведен", ПарольПроверенНаКлиенте);
Если Не ПарольПроверенНаКлиенте Тогда
Отказ = Истина;
ВызватьИсключение "Отмена проведения данного документа разрешена только интерактивно с вводом пароля!";
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Такой подход гарантирует 100% безопасность: ни одна обработка группового изменения реквизитов или внешняя интеграция не сможет распроводить документы, поскольку сервер заблокирует транзакцию без наличия специального свойства в структуре объекта.
Несмотря на то, что программные проверки с паролями работают, опытные разработчики и архитекторы 1С настоятельно рекомендуют отказаться от практики «зашивания» паролей в код. Это усложняет поддержку системы, снижает безопасность (пароль легко увидеть в коде или конфигураторе) и создает неудобства для пользователей.
В платформе «1С:Предприятие» предусмотрен стандартный, штатный механизм ограничения отмены проведения. Давайте разберем, как его настроить.
У каждого документа на уровне метаданных в роли определяются права доступа. Право на проведение и отмену проведения разделены:
Даже если в вашей конфигурации у большинства пользователей настроена роль ПолныеПрава (что само по себе является нарушением стандартов безопасности, но часто встречается на практике), вы можете поступить следующим образом:
АдминистраторДокументов.ПолныеПрава, если вы готовы ее кастомизировать) снимите галочку Интерактивная отмена проведения для целевых документов.В современных конфигурациях на базе БСП (например, 1С:ERP, 1С:Комплексная автоматизация или 1С:Управление торговлей) права пользователей гибко настраиваются через Группы доступа и Профили групп доступа прямо в режиме «1С:Предприятие». Вам достаточно просто исключить соответствующую роль из профилей обычных пользователей, не прибегая к программированию и изменению конфигурации.