← На главную

Многие разработчики, внедряющие Библиотеку Стандартных Подсистем (БСП) или работающие с конфигурациями на ее основе (ERP, КА, УТ, ЗУП), сталкиваются с предупреждением при запуске: "Найдены подключенные расширения конфигурации, изменяющие роли конфигурации". Часто возникает соблазн просто отключить эту проверку, но давайте разберемся, почему механизм безопасности реагирует именно так, какие риски это несет и как правильно решать задачи по ограничению прав доступа.

Суть проблемы: Механизм защиты БСП

В первую очередь, нам необходимо понять, как работает подсистема "Управление доступом" в БСП. Она не просто считывает права "на лету", а использует сложный механизм кэширования и дескрипторов доступа. Информация о правах хранится в служебных регистрах (например, ПраваРолей).

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

1. Нарушение логики Профилей групп доступа. В типовых конфигурациях существуют предопределенные профили (например, "Бухгалтер", "Кладовщик"), которые ссылаются на конкретные роли. Если мы в расширении "урезаем" права типовой роли, то описание профиля в пользовательском режиме перестает соответствовать действительности. Администратор видит, что право есть, а физически оно заблокировано расширением.
2. Проблемы с RLS (Record Level Security). Это наиболее критичный момент. Если типовая роль содержит шаблоны ограничений доступа (RLS), их модификация через расширение крайне затруднительна и часто приводит к ошибкам компиляции запросов доступа. Платформа может некорректно объединить текст ограничения из основной конфигурации и расширения.
3. Кэш и идентификаторы. БСП привязывает права к идентификаторам объектов метаданных. Изменение состава прав в расширении может привести к рассинхронизации справочника ИдентификаторыОбъектовМетаданных и реальных прав, вызывая ошибки при обновлении вспомогательных данных.

Принцип аддитивности прав

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

Если у пользователя есть две роли:

• Роль А (Типовая) — дает право на чтение справочника.
• Роль Б (Наша) — не дает права.

В итоге доступ будет разрешен. Чтобы запретить доступ, права не должно быть ни в одной из назначенных ролей.

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

Решение 1: Копирование роли (Рекомендуемый способ)

Наиболее надежный и безопасный способ ограничить права, не нарушая механизмы БСП — это создание собственной роли на основании типовой. Разберем этот алгоритм по шагам:

1. Открываем конфигуратор.
2. Находим типовую роль, которую нужно урезать (например, МенеджерПоПродажам).
3. Копируем эту роль и называем её по-своему, например, МенеджерПоПродажам_БезДоступаКЗарплате. На этом этапе поможет обработка для анализа прав и ролей.
4. В новой роли снимаем галочки с ненужных объектов (или настраиваем RLS).
5. В режиме "1С:Предприятие" создаем новый Профиль групп доступа, в который добавляем нашу новую роль вместо типовой. Визуализировать итоговую картину помогут отчеты по пользователям, ролям и профилям доступа.

Преимущества:

• Полная предсказуемость. Обновления типовой конфигурации не сломают вашу роль (хотя и не обновят её).
• Отсутствие конфликтов с БСП.
• Корректное отображение прав в интерфейсе администратора.

Недостатки:

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

Решение 2: Программное переопределение (Для продвинутых случаев)

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

Посмотрим на общий модуль УправлениеДоступомПереопределяемый. В нем можно внедрить свою логику проверок. Однако этот метод чаще используется для RLS, а не для полного отключения видимости объектов.

Если же речь идет именно о видимости объектов (справочников, документов), то без изменения ролей не обойтись.

Решение 3: Изменение в расширении (С осторожностью)

Если вы все же решили идти путем изменения типовой роли в расширении (на свой страх и риск, "навстречу паровозу", как выразились участники обсуждения), будьте готовы к следующему:

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

Этот метод допустим только для небольших изменений (например, добавление права на чтение одного нового отчета), но крайне не рекомендован для урезания прав.

Как добавить права через расширение?

Если ваша задача — не отнять, а добавить права (например, на новый справочник, добавленный в расширении), то менять типовые роли не нужно. Рассмотрим правильный подход:

1. Создайте в расширении новую роль (например, Расширение_ДопПрава).
2. Дайте этой роли права на ваши новые объекты.
3. Создайте в расширении профиль групп доступа (или добавьте роль в существующий программно/вручную), который включает эту роль.
4. Назначьте эту роль пользователям в дополнение к основным.

Так как права суммируются, пользователь получит доступ и к типовому функционалу (через типовую роль), и к вашему новому функционалу (через роль расширения).

Итог

Ошибка "Найдены подключенные расширения..." — это защита от некорректного проектирования системы прав.

Лучшая практика:

• Для добавления прав: создавайте новые роли в расширении и выдавайте их дополнительно.
• Для ограничения прав: копируйте типовую роль в основную конфигурацию (или расширение), урезайте права в копии и используйте её вместо типовой. Это требует сопровождения при обновлениях, но гарантирует стабильность работы базы.