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

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Многие разработчики и администраторы 1С сталкиваются с крайне неприятной ситуацией: создается расширение с собственной подсистемой, добавляется новая роль с правами на объекты этого расширения. Галочки назначаются пользователям (как рядовым, так и администраторам с полными правами) напрямую в Конфигураторе или через профили групп доступа в режиме Предприятия. Но вдруг, без видимых причин или после малейшего обновления расширения, эти галочки бесследно исчезают, а подсистема становится недоступна пользователям. Давайте подробно проанализируем эту ситуацию и разберем все доступные способы решения.

Выясним причину: почему слетают права?

Как мы выяснили из практики и обсуждений специалистов, истинная причина кроется во взаимодействии платформы 1С и механизмов Библиотеки стандартных подсистем (БСП), которая встроена в большинство современных типовых конфигураций (УНФ, УТ, Комплексная автоматизация, ERP и другие).

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

Рассмотрим по шагам основные и наиболее эффективные варианты решения этой проблемы, которые используют разработчики на практике.

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

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

  1. Откройте ваше расширение в Конфигураторе.
  2. Найдите общий модуль УправлениеДоступомСлужебный в основной конфигурации и добавьте его в расширение.
  3. Переопределите процедуру ОбновитьРолиПользователей с использованием аннотации &Вместо.
  4. Внутри переопределенной процедуры напишите код, который будет принудительно сохранять ваши роли перед выполнением типового алгоритма, либо исключать их из проверки.

Пример переопределения может выглядеть следующим образом:


&Вместо("ОбновитьРолиПользователей")
Процедура Расш1_ОбновитьРолиПользователей(Параметры)
    // Здесь размещаем алгоритм обхода очистки для наших специфических ролей
    // Сохраняем текущие значения ролей из расширения
    
    // Вызов стандартной процедуры БСП
    ПродолжитьВызов(Параметры);
    
    // Восстанавливаем галочки для нужных пользователей
КонецПроцедуры

Способ 2: Временное отключение регламентных заданий

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

  1. Перед применением обновления расширения в базе полностью заблокируйте выполнение регламентных заданий (например, через консоль администрирования серверов 1С).
  2. Обновите расширение и примените изменения.
  3. Назначьте нужные галочки и роли пользователям.
  4. Снова включите регламентные задания.

В этом случае фоновый процесс не "замечает" конфликта в момент изменения метаданных, и роли часто остаются на месте.

Способ 3: Внешняя обработка для бэкапа ролей

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

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

Способ 4: Настройка свойства "Использовать основные роли"

Посмотрим на настройки самого расширения. В корневом узле дерева метаданных расширения (двойной клик по названию расширения) откройте палитру свойств. Обратите внимание на свойство Использовать основные роли для всех пользователей.

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

Способ 5: Обновление типовой конфигурации

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

Поэтому, если вы используете устаревший релиз УТ, УНФ или ERP, самым правильным и долгосрочным решением будет обновление самой типовой конфигурации до актуального релиза. Это позволит избежать создания "костылей" и обеспечит штатную работу механизмов управления доступом.

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

← На главную