Почему слетают роли из расширения в 1С после обновления или перезапуска и как это исправить?

← На главную

Разработчики расширений в 1С часто сталкиваются с неприятной ситуацией: создается новая роль, она назначается пользователю через профиль групп доступа, всё работает корректно до первого обновления информационной базы или даже простого перезапуска сеанса. После этого роль «магическим» образом исчезает из списка назначенных прав пользователя. Особенно часто это проявляется у пользователей с полными правами (администраторов).

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

Выясняем причину: механизм контроля состава ролей в БСП

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

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

Рассмотрим основные способы решения этой проблемы — от быстрого «хака» до методологически правильного внедрения.

Решение 1: Модификация кода в общем модуле (программный метод)

Если нам необходимо, чтобы система перестала удалять роли с определенным префиксом у администраторов, мы можем внести изменения в логику работы БСП. Для этого найдем процедуру ОбновитьРолиПользователей в общем модуле УправлениеДоступомСлужебный.

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


// Фрагмент в процедуре ОбновитьРолиПользователей
Если Администраторы[ТекущийПользователь] <> Неопределено Тогда 
    ТекущиеНовыеРоли = НовыеРоли; 
    НовыеРоли = ТекущиеНовыеРоли.Скопировать(Новый Массив); 
    
    Для Каждого КлючИЗначение Из ОбязательныеРолиАдминистратора Цикл 
        НовыеРоли.Добавить.Роль = КлючИЗначение.Ключ; 
    КонецЦикла; 
    
    Для Каждого КлючИЗначение Из ДополнительныеРолиАдминистратора Цикл 
        Если ТекущиеНовыеРоли.Найти(КлючИЗначение.Ключ, "Роль") = Неопределено Тогда 
            Продолжить; 
        КонецЕсли; 
        НовыеРоли.Добавить.Role = КлючИЗначение.Ключ; 
    КонецЦикла; 

    // ВСТАВКА: Если для пользователя выбраны дополнительные роли из расширений 
    Для Каждого СтрокаТекущиеНовыеРоли Из ТекущиеНовыеРоли Цикл 
        // Здесь мы проверяем роль на наличие префикса вашего расширения
        Если Найти(ВРег(СтрокаТекущиеНовыеРоли.Роль), "ПРЕФИКС_") > 0 Тогда 
            НовыеРоли.Добавить.Роль = СтрокаТекущиеНовыеРоли.Роль; 
        КонецЕсли; 
    КонецЦикла; 
КонецЕсли;

Использование этого кода гарантирует, что при каждой проверке прав система будет видеть роли вашего расширения и оставлять их нетронутыми.

Решение 2: Использование свойства «Основная роль» в расширении

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

Это решение отлично подходит для «универсальных» расширений, функции которых должны быть доступны всем пользователям по умолчанию. Однако помните, что этот метод лишает вас возможности гибко управлять правами через Профили групп доступа — роль будет у всех или ни у кого.

Решение 3: Регистрация ролей через переопределяемые модули (Best Practice)

Методологически верным способом работы с БСП является использование программного интерфейса (API) библиотеки. Вместо правки служебных модулей (которые могут измениться при обновлении БСП), следует использовать переопределяемый модуль УправлениеДоступомПереопределяемый.

Разберем, как это сделать:

Найдем в модуле УправлениеДоступомПереопределяемый процедуру ПриОпределенииНазначенияРолей.
В этой процедуре мы можем явно указать системе, как следует трактовать роли из нашего расширения.
Мы можем добавить роль в список исключений, чтобы БСП не считала её «лишней» для определенных типов пользователей.

Этот подход гарантирует стабильность работы прав даже после масштабных обновлений конфигурации, так как вы используете штатные «точки входа», предусмотренные разработчиками фирмы 1С.

Решение 4: Корректное обновление идентификаторов метаданных

Иногда причина «слетания» ролей кроется в том, что система просто «не видит» новые объекты расширения в справочнике Идентификаторы объектов метаданных. Если роль добавлена в конфигураторе, но не зарегистрирована в данных в режиме 1С:Предприятие, механизмы защиты БСП могут её игнорировать. Для точечного обновления прав без перезапуска фоновых заданий БСП подойдёт обработка для пересчета прав доступа пользователей.

Выполним следующие шаги для синхронизации:

После внесения любых изменений в состав ролей расширения обязательно запустите базу с параметром командной строки: /СЗапускомОбновленияИнформационнойБазы.
Зайдите в справочник Профили групп доступа.
Найдите ваш профиль, в который включена роль из расширения. Выключите и снова включите флажок напротив этой роли, после чего нажмите «Записать и закрыть». Это инициирует принудительное обновление прав для всех участников групп доступа, использующих этот профиль.

Важные нюансы и рекомендации

При работе с ролями в расширениях стоит учитывать еще несколько технических моментов:

Безопасный режим: Если расширение подключено с установленным флажком «Безопасный режим», возможности по управлению доступом и программному изменению ролей могут быть ограничены. Если ваши роли требуют сложной логики проверки прав, попробуйте отключить безопасный режим (с согласия администратора системы).

Префиксы имен: Всегда следите за именованием. БСП корректно обрабатывает роли, если они имеют формат ИмяРасширения_ИмяРоли. Если имя роли в расширении дублирует имя роли из основной конфигурации или имеет некорректный формат, это может привести к коллизиям в механизме УправлениеДоступом.

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

Проанализировав вышеперечисленные методы, мы видим, что проблема «слетающих» ролей — это не ошибка платформы, а штатное поведение подсистемы управления доступом БСП. Используя либо программную корректировку в УправлениеДоступомСлужебный, либо регистрацию через УправлениеДоступомПереопределяемый, вы сможете добиться стабильной работы прав доступа в ваших расширениях.