Почему в расширении 1С не видны роли у пользователей без прав администратора?

← На главную

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

Анализ основной причины: безопасность платформы и объект ПользовательИнформационнойБазы

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


// Ошибочный подход для обычного пользователя
ТекущийПользовательИБ = ПользователиИнформационнойБазы.ТекущийПользователь();
Если ТекущийПользовательИБ.Роли.Содержит(Метаданные.Роли.МояНоваяРольИзРасширения) Тогда
    // Этот блок не выполнится для пользователя без полных прав
КонецЕсли;

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

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

Решение №1: Использование метода РольДоступна()

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

Проанализируем преимущества этого метода:

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

Пример правильной проверки:


// Правильный подход
Если РольДоступна("ИмяВашейРолиИзРасширения") Тогда
    // Логика для пользователя с ролью
Иначе
    // Логика для пользователя без роли
КонецЕсли;

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

Решение №2: Интеграция с Библиотекой Стандартных Подсистем (БСП)

В современных конфигурациях, таких как Комплексная автоматизация 2.4, ERP 2.5 или Управление торговлей 11, управление правами осуществляется через справочники профилей и групп доступа. Если вы просто добавили роль в расширение, она не появится автоматически в списке доступных для назначения в режиме «1С:Предприятие».

Разберем шаги по корректной регистрации роли расширения в системе прав БСП:

Обновление идентификаторов: После добавления роли в расширение необходимо запустить процедуру обновления справочника ИдентификаторыОбъектовМетаданных. Это можно сделать программно или через консоль запросов, вызвав метод: Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника();
Настройка профиля: Зайдите в раздел «Администрирование» — «Настройки пользователей и прав» — «Профили групп доступа». Найдите или создайте профиль, где будет отмечена ваша новая роль из расширения.
Назначение прав: Убедитесь, что пользователь включен в группу доступа, использующую данный профиль.

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

Решение №3: Свойства расширения и основные роли

Посмотрим на настройки самого расширения. В корневом элементе расширения есть важное свойство: «Использовать основные роли всех пользователей».

Проанализируем влияние этого флага:

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

Также обратите внимание на Режим совместимости расширения. Он должен соответствовать или быть ниже режима совместимости основной конфигурации. В платформе 8.3.14 были специфические баги, связанные с отображением ролей в расширениях, поэтому рекомендуется использовать актуальные версии платформы (например, 8.3.15 и выше), где работа с ролями расширений была значительно стабилизирована.

Решение №4: Использование альтернативных механизмов (Регистры сведений)

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

Алгоритм действий:

Создаем в расширении РегистрСведений.НастройкиДоступаПользователей.
Добавляем измерение Пользователь (тип СправочникСсылка.Пользователи) и ресурс ЗапретРеализацииПрошлымЧислом (тип Булево).
В коде проверки вместо обращения к ролям пишем запрос к этому регистру:


Функция ЕстьЗапретРедактирования()
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Настройки.ЗапретРеализацииПрошлымЧислом
        |ИЗ
        |   РегистрСведений.НастройкиДоступаПользователей КАК Настройки
        |ГДЕ
        |   Настройки.Пользователь = &ТекущийПользователь";
    
    Запрос.УстановитьПараметр("ТекущийПользователь", Пользователи.АвторизованныйПользователь());
    // ... выполнение запроса и возврат результата
КонецФункции

Преимущество такого метода: Гибкость настройки прав без необходимости изменения ролей в Конфигураторе и отсутствие зависимости от прав администратора при проверке. Однако, строго рекомендуется использовать стандартный механизм ролей и метод РольДоступна(), так как это соответствует архитектуре 1С и проще в поддержке.

Итоги и рекомендации

Выясним кратко, что нужно сделать, если роли в расширении «не видны»:

Никогда не используйте коллекцию ПользовательИнформационнойБазы.Роли для проверки прав обычных пользователей.
Используйте только функцию РольДоступна("ИмяРоли").
Убедитесь, что роль из расширения назначена пользователю через Профили групп доступа (БСП).
Проверьте, что в расширении включена опция «Использовать основные роли всех пользователей».
При использовании типовых конфигураций (КА, ERP) не забудьте обновить идентификаторы объектов метаданных.

Следуя этим правилам, вы обеспечите стабильную работу прав доступа в своих расширениях вне зависимости от обновлений платформы 1С.