При разработке расширений конфигурации часто возникает задача: добавить новые объекты (справочники, документы, обработки) и ограничить к ним доступ. Кажется логичным создать в расширении новую роль, выдать ее нужным пользователям и работать. Однако, когда дело доходит до пользователей с правами «Администратор» (Полные права), разработчики сталкиваются с загадочным поведением: выданная роль исчезает после первого входа пользователя в систему или спустя короткое время.
В этой статье мы подробно разберем, почему так происходит, как работает механизм обновления ролей в Библиотеке Стандартных Подсистем (БСП) и рассмотрим надежные способы решения этой проблемы.
Ситуация выглядит следующим образом: в базу добавляется расширение, содержащее новую роль, например, РольРасширения. Эта роль дает доступ к объектам расширения.
РольРасширения у него исчезает.ПолныеПрава и АдминистраторСистемы).Попытка выдать роль жестко через Конфигуратор помогает лишь временно. Как только срабатывает регламентное задание или процедура обновления параметров доступа при входе, «лишние» роли снова сбрасываются.
Причина кроется в защитных механизмах подсистем «Управление доступом» и «Пользователи». Разработчики типовых конфигураций (ERP, КА, ЗУП, Бухгалтерия и др.) заложили логику, гарантирующую, что у главного администратора всегда будет эталонный набор прав.
Давайте разберем, как система "мыслит":
Именно поэтому, добавленные вручную или через расширение роли считаются "мусором" и вычищаются.
Самый надежный способ, не требующий изменения программного кода и вмешательства в механизмы обновлений — перестать использовать предопределенную группу «Администраторы» для тех сотрудников, которым нужны специфические роли из расширений.
Давайте пройдем этот путь по шагам:
Шаг 1. Создание нового профиля групп доступа
Необходимо зайти в режим 1С:Предприятие под пользователем с полными правами. Перейдем в раздел Администрирование — Настройки пользователей и прав — Профили групп доступа.
Нам нужно создать новый профиль, который будет копией административного, но с нашей добавкой:
РольРасширения).Полные права и Администратор системы также стоят (они должны скопироваться из исходного профиля).Шаг 2. Создание группы доступа и назначение пользователей
Теперь создадим группу доступа на основе нового профиля:
Шаг 3. Исключение из стандартной группы
Это критически важный момент. Пользователь не должен состоять в старой группе Администраторы, иначе механизмы очистки могут сработать снова (в зависимости от приоритетов и версии БСП).
Теперь система видит, что пользователь относится к кастомному профилю. Для кастомных профилей жесткая логика "эталонных ролей" не применяется — система просто выдает набор ролей, отмеченных в профиле. Ваша роль из расширения останется на месте.
Если по каким-то причинам вы обязаны использовать именно предопределенную группу «Администраторы» (например, на неё завязана другая логика системы), вам придется вмешаться в код через расширение. Нам нужно "объяснить" системе, что нашу новую роль удалять нельзя.
В Библиотеке Стандартных Подсистем (БСП) существуют переопределяемые модули, позволяющие влиять на логику назначения прав.
Поиск нужного метода
В зависимости от версии БСП, название модуля и процедуры может отличаться. Чаще всего используются:
УправлениеДоступомПереопределяемыйПользователиПереопределяемыйНам необходимо найти процедуру, отвечающую за заполнение ролей, которые не должны отключаться или обновляться. Поищите в конфигурации процедуры с похожими названиями:
ПриЗаполненииНеотключаемыхРолейПользователейПриОбновленииРолейПользователяРеализация в расширении
Предположим, мы нашли подходящий метод ПриЗаполненииНеотключаемыхРолейПользователей в модуле УправлениеДоступомПереопределяемый. Нам нужно заимствовать этот модуль в расширение и доработать процедуру, используя аннотацию &После.
Примерный код реализации:
&После("ПриЗаполненииНеотключаемыхРолейПользователей")
Процедура Расш_ПриЗаполненииНеотключаемыхРолейПользователей(НеотключаемыеРоли)
// Добавляем имя нашей роли в список исключений
// Система не будет удалять эту роль у Администраторов
НеотключаемыеРоли.Добавить("МояСпециальнаяРольИзРасширения");
КонецПроцедуры
После применения этого кода и перезапуска сеанса, механизм обновления ролей БСП, увидев вашу роль в списке исключений, пропустит её при очистке профиля Администратора.
В вопросе автора темы прозвучала важная деталь: "По умолчанию все объекты расширения у меня доступны пользователям с ПолнымиПравами... Я добавил в расширение роль ПолныеПрава и снял права на объекты расширения".
Давайте проанализируем этот подход, так как он содержит потенциальные риски.
Риски заимствования роли "Полные права"
Заимствовать типовую роль ПолныеПрава в расширение и менять ей права (снимать галочки) — плохая практика.
ПолныеПрава (добавит новые объекты), ваше расширение может конфликтовать или перетирать эти настройки.Как правильно ограничить доступ?
В модели безопасности 1С действует принцип аддитивности: «Разрешено, если разрешено хотя бы в одной роли».
Если у пользователя есть роль ПолныеПрава, и в ней стоит галочка «Разрешить всё» (или глобальная настройка «Устанавливать права для новых объектов» в свойствах роли), то запретить доступ другой ролью невозможно. Запрещающих ролей в 1С (до версии платформы 8.3.2x с её усложненными механизмами) в явном виде нет.
Чтобы схема «Объекты расширения доступны только специальной роли» заработала, необходимо:
ПолныеПрава не имеет автоматического доступа к объектам расширения. К сожалению, для типовых ролей свойство «Устанавливать права для новых объектов» часто установлено в Истина. Это значит, любой новый справочник, который вы добавите, автоматически станет доступен админу.ПолныеПрава.Однако, если задача стоит просто раздать права другим пользователям, а администраторам оставить доступ "как есть", то лучшим решением будет:
Подведем итог решения проблемы исчезающих ролей:
УправлениеДоступомПереопределяемый, чтобы добавить роль в список неотключаемых.Используя эти методы, вы сможете гибко управлять доступом к функционалу расширений, сохраняя при этом порядок в правах пользователей.