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