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