Как получить роль пользователя в 1С

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

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

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

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

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

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

Обратите внимание: РольДоступна проверяет права именно текущего сеанса. Если код выполняется в привилегированном режиме, проверка ролей всё равно работает корректно — она относится к пользователю сеанса, а не к режиму исполнения. Но полагаться на РольДоступна внутри привилегированного кода для ограничения доступа к данным нельзя: сам доступ к данным в таком режиме уже не контролируется.

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

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

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

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

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

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

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

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

Если нужно узнать, какие роли фактически действуют для пользователя в типовой конфигурации, откройте отчёт «Права доступа» (в разделе администрирования) — он показывает права пользователя по объектам с указанием источника: роль или профиль группы доступа. Это быстрее, чем перебирать роли вручную.

Назначение и просмотр ролей в конфигураторе

Администратор без программирования может посмотреть и изменить роли пользователя в конфигураторе: меню «Администрирование» → «Пользователи», выбор пользователя, закладка «Прочие». Там отображаются доступные роли конфигурации и флажки назначенных. В файловых базах изменения применяются сразу, в клиент-серверных — после сохранения, пользователю может потребоваться перезайти в сеанс.

Сами роли и их состав прав настраиваются в дереве конфигурации: ветка «Общие» → «Роли». Открыв роль, вы видите матрицу прав по всем объектам метаданных. Это удобно, когда нужно понять, какие именно возможности даёт роль, прежде чем проверять её в коде.

1. 1
   Откройте конфигуратор и перейдите: Администрирование → Пользователи
2. 2
   Выберите нужного пользователя двойным щелчком
3. 3
   Перейдите на закладку «Прочие» — отмеченные флажки показывают назначенные роли
4. 4
   В типовой конфигурации дополнительно проверьте профили групп доступа в режиме предприятия

Проверка результата и типичные ошибки

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

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

Когда проверять право вместо роли

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

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

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

Частые вопросы