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