Просмотр ролей и прав доступа пользователя в 1С 8.3

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

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

Важная оговорка под типовые базы на БСП — Бухгалтерия 3.0, ЗУП 3.1, Управление торговлей 11. Роли пользователю здесь напрямую не назначают: они лежат внутри профилей групп доступа. Поэтому искать их нужно не там, где привыкли администраторы старых баз, и ниже разберём все способы по порядку.

Как роли связаны с правами в типовых конфигурациях

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

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

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

• 👤 Профиль групп доступа — набор ролей под конкретную должность (например, «Бухгалтер», «Кассир», «Только просмотр»).
• 🗂️ Группа доступа — связывает профиль с конкретными пользователями, иногда с дополнительным ограничением по организациям или складам.

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

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

Просмотр прав пользователя в режиме Предприятие

Это основной способ для администратора типовой базы — не нужен Конфигуратор и монопольный доступ.

1. Откройте Администрирование → Настройки пользователей и прав → Пользователи.
2. Найдите сотрудника в списке и откройте его карточку двойным щелчком.
3. Нажмите команду «Права доступа» (в зависимости от релиза — кнопка на форме или пункт в меню «Ещё»).

Откроется форма, где видно, в какие группы доступа входит пользователь и какие профили за ними стоят. Именно профили определяют его роли.

Чтобы посмотреть сами роли внутри профиля:

1. Зайдите в Администрирование → Настройки пользователей и прав → Профили групп доступа.
2. Откройте нужный профиль.
3. Перейдите на закладку с разрешёнными действиями — там перечислены все роли, входящие в профиль, с флажками.

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

Что показывает отчёт «Права доступа»

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

В нём обычно видно:

• список групп доступа пользователя и связанных профилей;
• роли, которые дают эти профили;
• дополнительные ограничения — по организациям, складам, видам документов, если они заданы в группе доступа.

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

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

Роли в Конфигураторе: редактор роли и список пользователей

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

Где смотреть состав роли:

1. Откройте базу в Конфигураторе.
2. В дереве конфигурации раскройте ветку Общие → Роли.
3. Дважды щёлкните нужную роль — откроется редактор.

В редакторе две основные части:

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

Чтобы увидеть, какие роли назначены пользователю на уровне информационной базы:

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

Сравнение способов: где смотреть

Проверка роли встроенным языком

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

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

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

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

Чтобы вывести все роли другого пользователя, перебирают коллекцию ролей конфигурации и проверяют каждую. Код выполняется на сервере:

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

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

Почему прав оказалось больше или меньше, чем нужно

Самая частая жалоба — «дали профиль, а пользователь либо видит лишнее, либо чего-то не хватает». Разбор сводится к нескольким проверкам.

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

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

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

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

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

Частые ошибки при настройке и просмотре ролей

Эти ошибки приводят не к неверному просмотру, а к тому, что настройки позже слетают или ведут себя непредсказуемо.

• ❌ Ставят флажки ролей в Конфигураторе на закладке «Прочие». В базах на БСП их перезапишет синхронизация с профилями. Назначать нужно через группы доступа.
• ❌ Правят поставляемый профиль. При обновлении состав ролей вернётся к типовому. Делайте копию профиля.
• ❌ Путают профиль и роль. Профиль — это набор ролей под должность; одна роль живёт в метаданных и разрешает конкретные действия. Пользователю назначают профиль, а не роль напрямую.
• ❌ Ищут «запрет» права. Запрещающих ролей нет: если право где-то разрешено, убрать его можно только исключив роль-источник, а не добавив «ограничивающую» роль сверху.
• ❌ Проверяют доступ под администратором. У пользователя с полными правами видно всё, и проблему воспроизвести нельзя. Проверяйте под учётной записью самого сотрудника или через отчёт «Права доступа».

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