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

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

Способ проверки зависит от типа конфигурации. В типовых решениях на Библиотеке стандартных подсистем (1С:ERP, УТ 11, КА 2, ЗУП 3, БП 3.0) роли назначаются через профили групп доступа, и смотреть их нужно в режиме предприятия. В старых или самописных конфигурациях роли задаются напрямую в конфигураторе. Ниже разобраны оба подхода, а также быстрые методы через запрос и встроенный язык.

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

Как устроены роли и профили доступа в 1С

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

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

Есть и третий уровень — ограничение доступа на уровне записей (RLS). Два пользователя с одинаковыми ролями могут видеть разный набор документов, если им заданы разные значения доступа. Это частая причина ситуации «роли одинаковые, а права разные».

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

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

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

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

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

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

В 1С:Бухгалтерии 3.0, ЗУП 3.1, УТ 11, ERP и КА 2 основной способ — просмотр групп доступа в режиме предприятия. Откройте раздел «Администрирование → Настройки прав и пользователей → Пользователи». В карточке пользователя есть ссылка «Права доступа» или табличная часть со списком групп доступа, в которые он включён.

Чтобы понять, какие именно роли даёт профиль, откройте «Администрирование → Настройки прав и пользователей → Группы доступа → Профили групп доступа». В карточке профиля перечислены разрешённые роли и, если включён соответствующий режим, ограничения по организациям, складам, контрагентам и другим значениям доступа.

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

Быстрая проверка прав из кода и через запрос

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

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

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

Функция ПравоДоступа() проверяет не роль, а конкретное право на объект метаданных — это точнее отражает реальные возможности пользователя, потому что учитывает сумму всех его ролей. Именно её стоит использовать, когда вопрос звучит как «может ли пользователь изменять этот документ».

Для получения списка пользователей и их профилей в типовых конфигурациях удобен запрос к справочникам «Пользователи» и «ПрофилиГруппДоступа» с табличной частью состава групп доступа. Такой запрос выполняется в консоли запросов и позволяет выгрузить матрицу «пользователь — профиль» для аудита.

Как проверить роли другого пользователя без его пароля

Функции РольДоступна() и ПравоДоступа() работают только для текущего сеанса. Чтобы оценить права другого сотрудника, не входя под его учётной записью, используйте отчёт «Права доступа» в типовой конфигурации — он строится для любого выбранного пользователя.

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

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

Почему роли есть, а доступа нет: типичные причины

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

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

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

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

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

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

FAQ