Почему функция РольДоступна() некорректно работает при наличии полных прав?

← На главную

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

Выясняем причину: механизмы синхронизации БСП

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

В современных конфигурациях (таких как ERP 2.4/2.5, УТ 11, БП 3.0) управление ролями в Конфигураторе происходит не вручную, а автоматически. БСП стремится оптимизировать список ролей пользователя. Если пользователю назначен профиль «Администратор», дающий роль ПолныеПрава, программная логика БСП может принять решение не добавлять другие специфические роли в список ролей этого пользователя в Конфигураторе. Логика системы проста: роль ПолныеПрава по умолчанию дает доступ ко всем объектам метаданных, следовательно, перечисление десятков дополнительных ролей излишне и лишь увеличивает размер кэша безопасности.

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

Различие между РольДоступна() и ПравоДоступа()

Для правильного решения задачи нам необходимо понимать фундаментальное различие между двумя методами проверки. Проанализируем их особенности:

РольДоступна("ИмяРоли") — проверяет именно факт назначения роли. Она не анализирует, какие права дает эта роль. Если проверка используется для ветвления логики (например, «показать кнопку, если есть роль Х»), то для администратора без этой роли кнопка исчезнет.
ПравоДоступа("Чтение", Метаданные.Справочники.ИмяСправочника) — проверяет наличие фактического права на объект. Для администратора с полными правами эта функция всегда вернет Истина, так как роль ПолныеПрава дает доступ ко всем объектам.

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

Решение 1: Проверка на две роли (классический подход)

Если вам все же нужно проверить наличие специфической функциональной роли, а не право на объект, самым простым и надежным способом будет добавление проверки на полные права в условие. Разберем пример кода:


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

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

Решение 2: Использование программного интерфейса БСП

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

Рассмотрим, как это выглядит в коде:


СписокРолей = "ИзменениеКодаЛПУ";
Если Пользователи.РолиДоступны(СписокРолей) Тогда
    // Код будет выполнен и для администратора, и для обладателя роли
КонецЕсли;

Внутри функции Пользователи.РолиДоступны() реализована логика: если текущий пользователь является администратором, функция сразу возвращает Истина, не проверяя остальные роли. Это избавляет разработчика от необходимости писать громоздкие условия Или РольДоступна(...) в каждом месте программы.

Проблема кэширования и привилегированного режима

Иногда даже при правильном коде роль может «не подхватываться». Разберем, на что стоит обратить внимание:

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