Как запретить интерактивное удаление объектов в расширении для пользователей с полными правами?

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

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

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

Суть проблемы: аддитивность прав в 1С

Прежде чем переходить к коду, давайте вспомним, как платформа 1С:Предприятие работает с правами доступа. Права в системе работают по принципу сложения (аддитивности). Это означает следующее:

  1. Если у пользователя есть две роли, и хотя бы одна из них разрешает действие (например, "Интерактивное удаление"), то действие будет разрешено.
  2. Запретить действие, которое разрешено в одной из назначенных ролей, путем создания новой роли с "отключенной галочкой" невозможно.

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

Давайте рассмотрим три способа решения этой задачи: от наименее рекомендуемого к наиболее надежному.

Способ 1. Изменение роли "Полные права" в расширении (Не рекомендуется)

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

Алгоритм действий:

  1. Находим в дереве метаданных основной конфигурации роль ПолныеПрава.
  2. Добавляем её в расширение.
  3. В расширении открываем права этой роли, находим наш справочник и снимаем флажок ИнтерактивноеУдаление.

Почему этот метод опасен?

Несмотря на простоту, этот подход несет серьезные риски при обновлении основной конфигурации. Если разработчик типового решения (например, 1С) добавит новые объекты (справочники, документы) и включит доступ к ним в роль ПолныеПрава, ваше расширение об этом "не узнает".

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

Способ 2. Скрытие кнопки "Удалить" на форме (Интерфейсное решение)

Если нам нужно просто защитить пользователя от случайного нажатия ("защита от дурака"), можно скрыть кнопку удаления из командной панели формы списка и формы элемента.

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

Давайте реализуем это в модуле формы расширения. Нам понадобится событие ПриСозданииНаСервере.


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

    // Вариант А: Скрытие стандартной команды формы
    ЭлементУдалить = Элементы.Найти("ФормаУдалить");
    Если ЭлементУдалить <> Неопределено Тогда
        ЭлементУдалить.Видимость = Ложь;
    КонецЕсли;

    // Вариант Б: Удаление из командной панели (более надежно для списков)
    // Обратите внимание: пользователь все равно может удалить через "Все функции" или Shift+Del,
    // если не заблокировать это на уровне прав.
    
    ТолькоПросмотр = Истина; // Это заблокирует и редактирование, и удаление

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

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

Способ 3. Подписка на событие (Самый надежный метод)

Чтобы гарантированно запретить удаление объекта, независимо от того, откуда оно вызвано (из формы списка, из обработки, через OData или COM-соединение), необходимо использовать механизм Подписок на события. Это "железобетонный" способ контроля целостности данных.

Мы создадим подписку на событие ПередУдалением для нашего справочника в расширении.

Шаг 1. Создание подписки в расширении

В дереве метаданных расширения создаем новую подписку на событие.
Источник: Ваш справочник (добавленный в расширение или заимствованный).
Событие: ПередУдалением.
Обработчик: Создаем новую процедуру в общем модуле расширения.

Шаг 2. Реализация логики запрета

В общем модуле напишем код, который будет проверять условия и отменять транзакцию удаления. В этом примере мы запретим непосредственное удаление (Shift+Delete) даже для пользователей с полными правами, но оставим возможность программного удаления при обмене данными. Для регулярной синхронизации баз в автоматическом режиме можно настроить автоматический обмен данными между базами 1С по расписанию.


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

    // 2. Логика проверки прав или условий
    // Даже если у пользователя Полные Права, мы можем запретить удаление.
    
    // Можно проверить имя пользователя или наличие специфической роли-исключения
    Если РольДоступна("ПолныеПрава") Тогда
        
        // Допустим, мы хотим разрешить удаление ТОЛЬКО специальному техническому пользователю
        Если ИмяПользователя() <> "ServiceAdmin" Тогда
            
            Отказ = Истина;
            
            Сообщение = Новый СообщениеПользователю;
            Сообщение.Текст = "Интерактивное удаление объектов этого справочника запрещено " 
                            + "административной политикой! Используйте пометку на удаление.";
            Сообщение.Сообщить();
            
        КонецЕсли;
        
    КонецЕсли;

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

Преимущества этого метода:

  1. Надежность: Работает на уровне платформы. Невозможно обойти через интерфейс.
  2. Безопасность обновлений: Мы не трогаем типовые роли и формы. Расширение живет своей жизнью и не конфликтует с обновлениями поставщика.
  3. Гибкость: В коде можно прописать любую логику: проверять дату создания объекта, его статус, автора или время суток.

Важное замечание о "Непосредственном удалении"

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

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

  1. Не давать права на интерактивное удаление в ваших собственных ролях.
  2. Использовать подписку на событие ПередУдалением, как описано выше, чтобы подстраховаться от роли ПолныеПрава.

Итог

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

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

← На главную