Как проверить роль пользователя программно в 1С

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

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

Ниже разобраны все рабочие варианты с примерами кода, ограничениями каждого подхода и типичными ошибками, которые приводят к тому, что проверка «молча» не срабатывает.

Какие способы проверки роли существуют в 1С

Платформа предлагает три основных механизма, и у каждого своя область применения. Неправильный выбор — частая причина того, что код работает у разработчика и не работает у пользователя.

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

Сравнение способов проверки роли

РольДоступна()

Проверяет только текущего пользователя сеанса. Простой и быстрый вариант, не требует прав администрирования.

ПользователиИнформационнойБазы

Позволяет проверить роль любого пользователя, но чтение списка пользователей требует соответствующих прав.

Функции БСП

Подходят для типовых конфигураций, учитывают профили групп доступа, но зависят от наличия библиотеки.

Проверка роли текущего пользователя через РольДоступна()

Функция РольДоступна(ИмяРоли) — самый короткий путь, когда нужно узнать, есть ли роль у того, кто сейчас выполняет код. Имя роли передаётся строкой так, как оно задано в конфигураторе (имя, а не синоним).

Типичный пример — скрыть кнопку удаления документов от всех, кроме пользователей с ролью «ПолныеПрава» или специальной роли администратора:

Если РольДоступна("ПолныеПрава") Тогда
Элементы.КнопкаУдалить.Видимость = Истина;
Иначе
Элементы.КнопкаУдалить.Видимость = Ложь;
КонецЕсли;

Можно проверить сразу несколько ролей, перечислив их через запятую — тогда функция вернёт Истина, если доступна хотя бы одна:

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

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

Как проверить роль произвольного пользователя

Когда нужно узнать роли не текущего, а другого пользователя — например, при построении отчёта по правам или при проверке перед назначением ответственного — используется менеджер ПользователиИнформационнойБазы.

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

ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("ИвановИИ");

Если ПользовательИБ = Неопределено Тогда
Сообщить("Пользователь не найден");
Иначе
РольПолныеПрава = Метаданные.Роли.Найти("ПолныеПрава");
Если РольПолныеПрава <> Неопределено
И ПользовательИБ.Роли.Содержит(РольПолныеПрава) Тогда
Сообщить("У пользователя есть полные права");
КонецЕсли;
КонецЕсли;

У этого способа есть ограничение: чтение списка пользователей информационной базы требует права «Администрирование» или соответствующих настроек. Обычный пользователь без таких прав получит ошибку доступа, поэтому подобный код размещают в серверных процедурах с установкой привилегированного режима — но только там, где это оправдано с точки зрения безопасности.

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

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

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

// Проверка полных прав текущего пользователя
Если Пользователи.ЭтоПолноправныйПользователь() Тогда
// доступ разрешён
КонецЕсли;

// Проверка полных прав конкретного пользователя
Если Пользователи.ЭтоПолноправныйПользователь(ПользовательСсылка) Тогда
// ...
КонецЕсли;

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

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

Проверка ПравоДоступа() устойчивее, чем проверка конкретной роли: если администратор создаст новую роль с теми же правами и назначит её пользователю, код с ПравоДоступа продолжит работать корректно, а проверка РольДоступна по старому имени — нет.

Пошаговый порядок добавления проверки роли в код

Чтобы проверка работала предсказуемо, полезно действовать по фиксированной схеме — от определения задачи до тестирования под разными учётными записями.

1. 1
   Определите, чью роль проверяете: текущего пользователя сеанса или произвольного из справочника
2. 2
   Уточните точное имя роли в конфигураторе (панель Роли, колонка Имя, не Синоним)
3. 3
   Для текущего пользователя добавьте проверку РольДоступна("ИмяРоли") в серверной процедуре
4. 4
   Для произвольного пользователя используйте ПользователиИнформационнойБазы.НайтиПоИмени() с проверкой на Неопределено
5. 5
   В типовой конфигурации замените прямую проверку на функции БСП или ПравоДоступа()
6. 6
   Протестируйте под учётной записью с ролью и без неё — оба случая должны отработать явно

Отдельно проверьте поведение при отсутствии роли в метаданных. Если роль с указанным именем не существует, РольДоступна() вызовет исключение, а Метаданные.Роли.Найти() вернёт Неопределено. В коде, который переносится между конфигурациями, стоит сначала проверять существование роли через метаданные.

Типичные ошибки при проверке ролей

Большинство проблем с программной проверкой ролей сводится к нескольким повторяющимся ошибкам. Знание их заранее экономит часы отладки.

Отдельная группа проблем — кэширование. Если роль назначили пользователю во время его сеанса, изменения подействуют не сразу: пользователю нужно перезайти в систему. При тестировании это часто выглядит как «код не работает», хотя проблема в устаревшем сеансе.

Как убедиться, что проверка работает правильно

Проверка роли считается внедрённой корректно, только если она протестирована минимум под двумя учётными записями: с нужной ролью и без неё. Тест под одним администратором не показывает ничего — у него доступно всё.

Контрольные точки

Как проверить результат

Поведение под пользователем с ролью

Норма

Действие выполняется, интерфейсные элементы доступны

Тревожный признак

Доступ заблокирован — проверьте имя роли и перезапуск сеанса

Поведение под пользователем без роли

Норма

Действие запрещено и на клиенте, и на сервере

Тревожный признак

Кнопка скрыта, но серверная операция доступна — защита неполная

Пользователь не найден в базе

Норма

Код обрабатывает ситуацию через проверку на Неопределено

Тревожный признак

Возникает исключение и прерывание обработки

Роль переименована в конфигураторе

Норма

Используется ПравоДоступа — логика не пострадала

Тревожный признак

Проверка по строковому имени перестала работать

Для массовой проверки назначенных ролей удобно вывести список всех пользователей с их ролями в журнал регистрации или табличный документ — это помогает найти учётные записи с избыточными правами. Такой аудит стоит проводить после любого изменения ролевой модели.

Частые вопросы о проверке ролей в 1С

Чем РольДоступна() отличается от ПравоДоступа()?

РольДоступна() проверяет наличие конкретной роли по её имени, а ПравоДоступа() — наличие права (Чтение, Изменение и т.д.) на объект метаданных независимо от того, через какую роль оно получено. Второй вариант устойчивее к изменениям ролевой модели и предпочтительнее в прикладном коде.

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

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

Можно ли проверить роль пользователя, не являясь администратором?

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

Как проверить роль внешнего пользователя в типовой конфигурации?

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

Что произойдёт, если роль с указанным именем не существует в конфигурации?

РольДоступна() вызовет исключение, прерывающее выполнение кода. Поэтому в переносимых решениях сначала проверяют Метаданные.Роли.Найти("ИмяРоли") на Неопределено и только потом вызывают проверку.

Нужно ли дублировать проверку роли на клиенте и на сервере?

Да, если речь о реальном ограничении доступа. Клиентская проверка управляет только удобством (видимостью кнопок), но её легко обойти. Серверная проверка в момент выполнения операции обязательна — именно она является защитой.