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