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

В типовых и самописных конфигурациях 1С часто требуется узнать программно, есть ли у пользователя право на определённый объект: документ, справочник, регистр или целое действие вроде проведения или удаления. Такая проверка нужна при динамической настройке интерфейса, в бизнес-процессах, при выдаче предупреждений и в обработках, которые должны работать по-разному в зависимости от полномочий текущего сотрудника.

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

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

Чем отличаются право, роль и доступ к данным

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

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

Проверка права на объект метаданных: функция ПравоДоступа

Основной инструмент — функция ПравоДоступа(Право, ОбъектМетаданных). Она возвращает булево значение и применяется только к текущему пользователю сеанса. Типовой пример — скрыть команду проведения, если пользователю запрещено проведение документа:

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

Имена прав указываются строкой и должны соответствовать типу объекта. Для документов доступны права «Проведение» и «ОтменаПроведения», для справочников их нет — попытка проверить несуществующее право приведёт к ошибке. Для регистров сведений и накопления актуальны «Чтение», «Изменение», «Добавление», «Удаление». Для самой информационной базы проверяются права «Администрирование», «ТонкийКлиент», «ВебКлиент» и другие через Метаданные без указания конкретного объекта:

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

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

Если ПравоДоступа("Изменение", Метаданные.Справочники.Контрагенты) Тогда
    Сообщить("Изменение контрагентов разрешено");
Иначе
    Сообщить("Доступ запрещён");
КонецЕсли;

Проверка роли текущего пользователя: функция ЕстьРоль

Когда нужно узнать, назначена ли пользователю конкретная роль, используется функция ЕстьРоль(ИмяРоли). Она также работает только для текущего сеанса и возвращает Истина, если роль назначена напрямую. Типичный сценарий — показать расширенные команды обработки только сотрудникам с ролью «Завскладом»:

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

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

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

Проверка прав другого пользователя

Задача «узнать права не текущего, а произвольного сотрудника» встречается в отчётах по доступу и в обработках аудита. Здесь ПравоДоступа и ЕстьРоль не помогут — они жёстко привязаны к текущему сеансу. Вместо них используется менеджер ПользователиИнформационнойБазы:

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

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

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

Учёт привилегированного режима и безопасного контекста

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

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

Практический сценарий: диагностическая обработка

На практике удобно собрать проверки в одну служебную обработку, которую администратор запускает при жалобах «не вижу документ» или «нет кнопки». Логика простая: обработка принимает имя пользователя и список объектов, затем выводит таблицу с результатами проверок.

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

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

Типичные ошибки при программной проверке прав

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

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

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

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