Как переопределить открытие формы объекта в зависимости от прав доступа пользователя?

← На главную

В практике разработки на платформе 1С:Предприятие часто возникает задача разграничения интерфейса для разных категорий пользователей. Классический пример: администратор должен видеть расширенную карточку сотрудника с техническими данными, а обычный пользователь — упрощенную форму только с контактной информацией. Давайте разберем подробно, как реализовать подмену формы "на лету" при открытии объекта.

Постановка задачи

У нас есть справочник Сотрудники. В конфигурации созданы две разные формы элемента:

ФормаПользователя — для сотрудников без административных прав.
ФормаАдминистратора — для пользователей с ролью "Администрирование" (содержит дополнительные поля: пароль, уникальный идентификатор и т.д.).

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

Решение 1: Использование события ОбработкаПолученияФормы

Самый надежный и правильный способ перехватить обращение к форме объекта — это использование предопределенной процедуры ОбработкаПолученияФормы в модуле менеджера объекта. Этот метод срабатывает при любом способе открытия: из списка, по ссылке или программно.

Рассмотрим пошаговую реализацию:

Откройте модуль менеджера справочника Сотрудники.
Добавьте процедуру ОбработкаПолученияФормы.
Внутри процедуры нам необходимо проверить вид запрашиваемой формы и наличие прав у пользователя.

Разберем код, который необходимо написать:


Процедура ОбработкаПолученияФормы(Источник, ВидФормы, Параметры, ВыбраннаяФорма, ДополнительнаяИнформация, СтандартнаяОбработка)
	
	// 1. Проверяем, что система запрашивает именно форму объекта (карточку), 
	// а не форму списка или выбора.
	Если ВидФормы = "ФормаОбъекта" Тогда
		
		// 2. Проверяем наличие роли у текущего пользователя.
		// Функция РольДоступна("ИмяРоли") возвращает Истина, если роль есть.
		Если РольДоступна("Администрирование") Тогда
			
			// 3. Указываем путь к форме для администратора
			ВыбраннаяФорма = "Справочник.Сотрудники.Форма.ФормаАдминистратора";
			
		Иначе
			
			// 4. Указываем путь к форме для обычного пользователя
			ВыбраннаяФорма = "Справочник.Сотрудники.Форма.ФормаПользователя";
			
		КонецЕсли;
		
		// 5. Отключаем стандартную обработку, чтобы платформа приняла наш выбор
		СтандартнаяОбработка = Ложь;
		
	КонецЕсли;

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

Обратите внимание на параметр ВидФормы. Проверка Если ВидФормы = "ФормаОбъекта" критически важна. Если ее не сделать, этот код попытается подсунуть форму элемента даже тогда, когда пользователь открывает список сотрудников, что приведет к ошибке.

Улучшение кода: Безопасное указание формы

Использование строковых литералов (путей в кавычках) типа "Справочник.Сотрудники.Форма..." может быть небезопасным. Если вы или другой разработчик переименуете форму в конфигураторе, код перестанет работать, но ошибка возникнет только в режиме Предприятия.

Давайте улучшим решение, используя объекты метаданных. В этом случае, если имя формы изменится, платформа предупредит вас при проверке конфигурации.


Процедура ОбработкаПолученияФормы(Источник, ВидФормы, Параметры, ВыбраннаяФорма, ДополнительнаяИнформация, СтандартнаяОбработка)
	
	Если ВидФормы = "ФормаОбъекта" Тогда
		
		СтандартнаяОбработка = Ложь;
		
		Если РольДоступна("Администрирование") Тогда
			// Обращаемся через коллекцию Метаданных
			ВыбраннаяФорма = Метаданные.Справочники.Сотрудники.Формы.ФормаАдминистратора;
		Иначе
			ВыбраннаяФорма = Метаданные.Справочники.Сотрудники.Формы.ФормаПользователя;
		КонецЕсли;
		
	КонецЕсли;

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

Решение 2: Архитектурный подход (Единая форма)

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

Более грамотный подход — использовать одну форму, но управлять видимостью элементов программно при её создании.

Давайте посмотрим, как это сделать. Оставим только одну основную форму объекта и напишем код в модуле этой формы в процедуре ПриСозданииНаСервере:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
	
	// Проверяем права пользователя
	ЭтоАдминистратор = РольДоступна("Администрирование");
	
	// Управляем видимостью элементов формы
	// Элементы, которые должен видеть ТОЛЬКО администратор
	Элементы.ГруппаСлужебнойИнформации.Видимость = ЭтоАдминистратор;
	Элементы.Пароль.Видимость = ЭтоАдминистратор;
	Элементы.УникальныйИдентификатор.Видимость = ЭтоАдминистратор;
	
	// Если пользователь не админ, можно также запретить редактирование
	Если Не ЭтоАдминистратор Тогда
		ЭтаФорма.ТолькоПросмотр = Истина;
	КонецЕсли;

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

Такой подход делает конфигурацию легче и проще в поддержке.

Важные нюансы безопасности

Мы должны помнить, что переопределение формы или скрытие полей через Видимость — это только интерфейсное (визуальное) ограничение.

Кеширование: Платформа кеширует настройки форм. Если вы тестируете логику переключения форм, иногда может потребоваться перезапуск сеанса, чтобы изменения вступили в силу.
Доступ к данным: Если вы скрыли поле "Зарплата" на форме, но не ограничили доступ на уровне прав (RLS), продвинутый пользователь сможет увидеть эти данные через отчеты, внешние обработки или механизм "Все функции".

Для надежной защиты данных используйте настройку ролей и RLS (Record Level Security), а управление формами оставьте для удобства пользователей.