Как в БП 3.0 и ЗУП 3.1 запретить пользователям с полными правами изменять дату запрета редактирования

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

В типовых конфигурациях 1С, таких как Бухгалтерия предприятия 3.0 и Зарплата и управление персоналом 3.1, пользователи с ролью Полные права обладают практически неограниченными возможностями. Однако в крупных организациях часто возникает задача ограничить даже администраторов в части изменения даты запрета редактирования данных. Рассмотрим, почему нельзя просто «снять галочку» в типовой роли и как правильно реализовать это ограничение с помощью расширения конфигурации.

Почему не стоит редактировать типовую роль Полные права

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

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

Поэтому мы разберем более изящный способ — программное ограничение через расширение с использованием так называемой «роли-маркера».

Способ 1. Использование «роли-маркера» и блокировка на уровне регистра

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

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

Создадим в расширении новую роль, например, РазрешитьИзменениеДатыЗапрета. Права на объекты этой роли давать не нужно. Она будет служить лишь признаком (маркером), что данному пользователю разрешено действие.

Шаг 2. Программная проверка в модуле набора записей

Добавим в расширение регистр сведений ДатыЗапретаИзменения и создадим обработчик события ПередЗаписью в модуле набора записей. Пропишем логику, которая будет проверять наличие нашей новой роли.


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

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

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

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

Способ 2. Управление интерфейсом через расширение формы

Чтобы не вводить пользователя в заблуждение кнопками, которые не работают, проанализируем ситуацию в интерфейсе. Нам нужно закрыть доступ к самой форме настройки дат запрета.

Рассмотрим подробнее модификацию общей формы ДатыЗапретаИзменения. Добавим её в расширение и создадим обработчик ПриСозданииНаСервере.


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

Способ 3. Модификация служебных методов (ИзменениеИКонтроль)

Посмотрим на пример работы с общим модулем ДатыЗапретаИзмененияСлужебный. Это более «глубокий» уровень вмешательства. Мы можем использовать директиву &ИзменениеИКонтроль для метода, отвечающего за установку параметров сеанса.

Это позволит оперативно следить за изменениями в типовом коде при обновлениях. Если 1С изменит структуру хранения дат, расширение выдаст предупреждение, и мы сможем адаптировать код.

Важный нюанс: механизм дат запрета активно кэширует данные в параметрах сеанса УстановленныеДатыЗапретаИзменения. Если вы программно запретили запись, но пользователь уже что-то изменил в памяти, необходимо убедиться, что кэш не будет обновлен некорректно. Программная блокировка на уровне регистра (Способ 1) полностью решает эту проблему, так как кэш обновляется только после успешной записи в базу данных.

Итоговый алгоритм настройки в программе

После того как расширение написано и подключено, выполним следующие действия в режиме «1С:Предприятие»:

  1. Перейдем в раздел Администрирование — Настройки пользователей и прав.
  2. Создадим новый Профиль групп доступа, назовем его «Право изменения даты запрета».
  3. В списке разрешенных ролей этого профиля выберем только нашу новую роль РазрешитьИзменениеДатыЗапрета из расширения.
  4. Создадим новую Группу доступа, выберем созданный профиль и добавим в список только тех пользователей, которым действительно разрешено двигать дату запрета.
  5. У всех остальных пользователей (включая тех, у кого есть «Администратор» или «Полные права») этого профиля не будет, а значит, сработает наша блокировка в расширении.

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

← На главную