Как реализовать открытие разных форм документа в зависимости от роли пользователя в 1С?

← На главную

При разработке сложных конфигураций на платформе 1С:Предприятие 8.3 часто возникает задача разделения интерфейса для разных категорий сотрудников. Например, администратору необходимо видеть все технические поля документа в расширенной форме, в то время как рядовому менеджеру достаточно упрощенного представления. В этой статье мы подробно разберем, как реализовать механизм переопределения форм, опираясь на лучшие практики программирования и возможности Библиотеки стандартных подсистем (БСП).

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

Наиболее правильным и архитектурно верным способом подмены формы является использование события ОбработкаПолученияФормы. Это событие располагается в модуле менеджера конкретного объекта метаданных (документа, справочника и т.д.). Рассмотрим подробнее, почему стоит выбирать именно этот метод.

Когда система получает запрос на открытие формы (интерактивно из списка или программно через метод ПолучитьФорму()), она первым делом обращается к модулю менеджера. Если мы переопределим форму здесь, система даже не начнет инициализировать стандартную форму, что существенно сэкономит ресурсы сервера и время пользователя.

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


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

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

В данном примере мы анализируем параметр ВидФормы. Если запрашивается ФормаОбъекта, мы проверяем права текущего пользователя. Если условие выполняется, мы присваиваем переменной ВыбраннаяФорма имя нужной нам формы (строкой, как она называется в метаданных) и обязательно устанавливаем СтандартнаяОбработка = Ложь, чтобы система не пыталась открыть основную форму по умолчанию.

Почему нельзя использовать ПередОткрытием в модуле формы?

Часто начинающие разработчики пытаются решить задачу "в лоб": в модуле стандартной формы в событии ПередОткрытием прописывают отказ и открывают другую форму. Проанализируем, почему это плохая практика:

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

Как справедливо отмечено в обсуждении, использование ПередОткрытием — это "костыль", который работает, но делает систему менее стабильной и производительной.

Альтернативный подход: Одна адаптивная форма

Иногда создание нескольких разных форм избыточно. Если отличия заключаются лишь в видимости нескольких полей или кнопок, эффективнее использовать одну форму, но динамически изменять её интерфейс. Это делается в процедуре ПриСозданииНаСервере модуля формы.

Посмотрим на пример реализации:


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

Преимущества этого метода:

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

Проверка прав: Роли или Группы доступа?

В ходе обсуждения возник важный спор: использовать функцию РольДоступна() или проверять вхождение пользователя в Группы доступа. Проанализируем ситуацию.

Функция РольДоступна() является стандартным методом платформы. Однако в типовых решениях (УТ 11, ERP, БП 3.0), использующих БСП, роли могут назначаться динамически через профили групп доступа. Специалисты рекомендуют использовать программный интерфейс БСП — функцию УправлениеДоступом.ЕстьРоль(). Она корректно обрабатывает ситуацию с полными правами и более надежна в типовых конфигурациях.

Что касается проверки конкретной Группы доступа по наименованию (через запрос к справочнику ГруппыДоступа), то это считается менее гибким решением. Наименование группы в пользовательском режиме может изменить любой администратор, что приведет к поломке программного кода. Если вы все же решили использовать этот метод, лучше искать группу по предопределенному идентификатору или использовать функциональные опции.

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

При реализации подмены форм важно помнить о следующих моментах:

Кэширование: Система 1С кэширует информацию о том, какую форму открывать. Если вы изменили роль пользователя, а форма осталась старой — попробуйте перезапустить сеанс.
Доступ через "Функции для технического специалиста": Помните, что подмена формы — это визуальное ограничение. Если у пользователя есть права на сам объект метаданных, он теоретически может добраться до данных другими способами. Настоящая безопасность обеспечивается настройкой RLS (Record Level Security) и ролями в Конфигураторе.
Функциональные опции: Если показ новой формы зависит не просто от роли, а от включенной настройки в константах, используйте Функциональные опции. Это "штатный" механизм платформы для скрытия/показа элементов интерфейса без написания лишнего кода.

Подводя итог, можно сказать: если формы различаются кардинально — используйте ОбработкаПолученияФормы в модуле менеджера. Если различия косметические — управляйте видимостью элементов в ПриСозданииНаСервере. Всегда отдавайте предпочтение методам БСП для проверки прав, чтобы ваш код оставался чистым и легко обновляемым.