В типовых конфигурациях 1С, таких как Бухгалтерия предприятия 3.0 и Зарплата и управление персоналом 3.1, пользователи с ролью Полные права обладают практически неограниченными возможностями. Однако в крупных организациях часто возникает задача ограничить даже администраторов в части изменения даты запрета редактирования данных. Рассмотрим, почему нельзя просто «снять галочку» в типовой роли и как правильно реализовать это ограничение с помощью расширения конфигурации.
Проанализируем ситуацию: роль Полные права в платформе 1С:Предприятие 8.3 является привилегированной. Если у пользователя установлена эта роль, система игнорирует ограничения на уровне записей (RLS). Попытка напрямую отредактировать эту роль в конфигурации или расширении может привести к следующим проблемам:
ДатыЗапретаИзменения, некоторые процедуры обновления базы могут завершиться с ошибкой.Поэтому мы разберем более изящный способ — программное ограничение через расширение с использованием так называемой «роли-маркера».
Этот метод считается наиболее надежным, так как он срабатывает при любой попытке записи данных, будь то форма или программный код. Разберем его по шагам.
Шаг 1. Создание роли в расширении
Создадим в расширении новую роль, например, РазрешитьИзменениеДатыЗапрета. Права на объекты этой роли давать не нужно. Она будет служить лишь признаком (маркером), что данному пользователю разрешено действие.
Шаг 2. Программная проверка в модуле набора записей
Добавим в расширение регистр сведений ДатыЗапретаИзменения и создадим обработчик события ПередЗаписью в модуле набора записей. Пропишем логику, которая будет проверять наличие нашей новой роли.
&После("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ, Замещение)
// Если запись инициирована системными механизмами (например, при обновлении),
// ОбменДанными.Загрузка будет Истина. В этом случае не блокируем.
Если ЭтотОбъект.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Проверяем наличие специальной роли у текущего пользователя
Если Не РолиДоступны("РазрешитьИзменениеДатыЗапрета") Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "У вас недостаточно прав для изменения даты запрета редактирования.
|Обратитесь к главному администратору для получения специального профиля.";
Сообщение.Сообщить();
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Выясним причину использования именно события ПередЗаписью: оно срабатывает всегда, даже если пользователь попытается изменить дату через «Групповое изменение реквизитов» или внешнюю обработку.
Чтобы не вводить пользователя в заблуждение кнопками, которые не работают, проанализируем ситуацию в интерфейсе. Нам нужно закрыть доступ к самой форме настройки дат запрета.
Рассмотрим подробнее модификацию общей формы ДатыЗапретаИзменения. Добавим её в расширение и создадим обработчик ПриСозданииНаСервере.
&После("ПриСозданииНаСервере")
Процедура Расш1_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверяем наличие нашей роли-маркера
Если Не РолиДоступны("РазрешитьИзменениеДатыЗапрета") Тогда
// Вариант 1: Полный запрет входа в форму
// Сообщить("Настройка дат запрета доступна только ответственным лицам.");
// Отказ = Истина;
// Вариант 2: Только просмотр
ЭтотОбъект.ТолькоПросмотр = Истина;
// Дополнительно можно скрыть конкретные кнопки
Элементы.ГруппаКоманднаяПанель.Видимость = Ложь;
КонецЕсли;
КонецПроцедуры
Посмотрим на пример работы с общим модулем ДатыЗапретаИзмененияСлужебный. Это более «глубокий» уровень вмешательства. Мы можем использовать директиву &ИзменениеИКонтроль для метода, отвечающего за установку параметров сеанса.
Это позволит оперативно следить за изменениями в типовом коде при обновлениях. Если 1С изменит структуру хранения дат, расширение выдаст предупреждение, и мы сможем адаптировать код.
Важный нюанс: механизм дат запрета активно кэширует данные в параметрах сеанса УстановленныеДатыЗапретаИзменения. Если вы программно запретили запись, но пользователь уже что-то изменил в памяти, необходимо убедиться, что кэш не будет обновлен некорректно. Программная блокировка на уровне регистра (Способ 1) полностью решает эту проблему, так как кэш обновляется только после успешной записи в базу данных.
После того как расширение написано и подключено, выполним следующие действия в режиме «1С:Предприятие»:
РазрешитьИзменениеДатыЗапрета из расширения.Таким образом, мы сохраняем типовую роль Полные права в девственном виде, обеспечивая стабильность обновлений, и при этом гибко управляем критически важной настройкой системы.