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