Почему РольДоступна() возвращает Ложь, если у пользователя полные права, и как правильно проверять роли в 1С?

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

Анализируем причину: особенность работы функции РольДоступна()

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

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

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

Правильный способ проверки ролей: используем Библиотеку стандартных подсистем (БСП)

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

Эта функция называется Пользователи.РолиДоступны().

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

Посмотрим на пример. Предположим, мы добавили роль ДоступКДополнительномуОтчету.

Неправильная проверка, которая не сработает для администратора:

Если РольДоступна("ДоступКДополнительномуОтчету") Тогда
    // Этот код не выполнится для пользователя с полными правами,
    // даже если ему для порядка назначили эту роль.
    Сообщить("У вас есть доступ!");
КонецЕсли;

Правильная проверка с использованием БСП:

Если Пользователи.РолиДоступны("ДоступКДополнительномуОтчету") Тогда
    // Этот код выполнится и для пользователя с ролью "ДоступКДополнительномуОтчету",
    // и для пользователя с полными правами.
    Сообщить("У вас есть доступ!");
КонецЕсли;

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

Современный подход к настройке прав доступа

Проблема, описанная в теме, также подсвечивает важность понимания современной модели управления правами в 1С. Прямое назначение ролей пользователям в конфигураторе — устаревший подход, который не используется в сложных конфигурациях, таких как КА 2.4, ERP или УТ 11. Вместо этого применяется гибкая многоуровневая система. Разберем ее по шагам.

1. Создание ролей в Конфигураторе. Этот шаг остается неизменным. Роль как объект метаданных, определяющий набор разрешенных действий (чтение, запись, проведение и т.д.), по-прежнему создается исключительно в конфигураторе. Это "атомы" прав.
2. Объединение ролей в Профили групп доступа. В режиме "1С:Предприятие" (в разделе НСИ и Администрирование -> Настройки пользователей и прав) создаются Профили групп доступа. Профиль — это логическая сущность, соответствующая должности или функциональной обязанности сотрудника (например, "Менеджер по продажам", "Кладовщик", "Бухгалтер по расчету зарплаты"). В каждый профиль включается одна или несколько ролей из конфигуратора. Именно на этом этапе ваша новая роль должна быть добавлена в соответствующий профиль.
3. Создание Групп доступа. На основе Профилей создаются Группы доступа. Группа доступа — это экземпляр профиля, к которому можно применить дополнительные ограничения на уровне записей (RLS). Например, можно создать две группы доступа ("Менеджеры по оптовым продажам" и "Менеджеры по розничным продажам") на основе одного профиля "Менеджер по продажам", но с разными ограничениями по складам или организациям.
4. Включение пользователей в Группы доступа. На последнем шаге конкретные пользователи включаются в одну или несколько созданных Групп доступа. Таким образом, пользователь получает права не напрямую от ролей, а опосредованно, через участие в группах.

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

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