Почему функция РольДоступна возвращает Ложь при назначении роли через профили и группы доступа БСП?

← На главную

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

Принцип работы платформенной функции РольДоступна

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

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

Основные причины, почему роль не определяется платформой

Проанализируем ключевые причины, из-за которых РольДоступна() возвращает отрицательный результат:

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

Где в коде БСП происходит назначение ролей пользователям

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

Посмотрим на пример вызова процедур обновления:


// Модуль объекта справочника "ГруппыДоступа"
ОбновитьРолиПользователейПриИзмененииГруппыДоступа(ПарольПользователяСервиса);

// Общий модуль "УправлениеДоступомСлужебный"
УправлениеДоступомСлужебный.ОбновитьРолиПользователей(МассивПользователей, ПарольПользователяСервиса);

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

Как правильно выполнять проверку прав в конфигурациях на БСП

По стандартам разработки «1С» прямой вызов метода РольДоступна() в прикладном коде не рекомендуется. Разберем правильные варианты проверки прав:

Использование функций БСП вместо платформенного метода. Для проверки доступности роли следует вызывать функцию Пользователи.РолиДоступны() или ПользователиКлиентСервер.РолиДоступны(). Она учитывает административные права, наличие роли ПолныеПрава и привилегированный режим:
```
// Проверка одной или нескольких ролей через БСП
Если Пользователи.РолиДоступны("ДобавлениеИзменениеДокументовПродажи") Тогда
    // Действие доступно пользователю или администратору
КонецЕсли;
```
Проверка прав к конкретным объектам метаданных. Если необходимо определить, может ли пользователь читать или редактировать объект, надежнее использовать метод ПравоДоступа(), а не проверять конкретную роль по имени:
```
// Проверка фактического права на объект
Если ПравоДоступа("ИнтерактивноеДобавление", Метаданные.Документы.РеализацияТоваровУслуг) Тогда
    // Разрешено создание документа
КонецЕсли;
```
Обновление метаданных при добавлении новых ролей. Если роль только что создана, выполним обновление данных подсистемы: Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанные();

Таким образом, для стабильной работы механизмов доступа в конфигурациях на базе БСП необходимо использовать специализированные методы Пользователи.РолиДоступны(), контролировать перезапуск сеанса после изменения групп доступа и учитывать внутреннюю оптимизацию платформы и библиотечных модулей.