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