Семь способов узнать, какие права у пользователя 1С

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

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

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

Группы доступа в режиме «1С:Предприятие»

Начните отсюда — Конфигуратор для этого не нужен, прав администратора базы достаточно.

Откройте Администрирование → Настройки пользователей и прав → Пользователи. Двойной щелчок по строке открывает карточку пользователя. На ней:

• 🧩 Группы доступа — набор профилей, назначенных пользователю. Это и есть то, что реально даёт права.
• 🔑 Вход в программу разрешён — если флажок снят, человек не войдёт независимо от прав.
• 👤 Отдельная кнопка/ссылка профилей — ведёт к профилям групп доступа, из которых собраны права.

Чтобы увидеть, что именно даёт конкретный профиль, перейдите в Настройки пользователей и прав → Профили групп доступа. Откройте профиль — на закладке с разрешёнными действиями видно список ролей, которые в него входят, а на закладке ограничений — виды доступа (по организациям, складам, контрагентам и т. п.).

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

Такой обзор отвечает на вопрос «что человеку в принципе разрешено». Детализацию до отдельных объектов даёт отчёт из следующего раздела.

Отчёт по правам доступа пользователя

В типовых конфигурациях на базе библиотеки стандартных подсистем (БП 3.0, ЗУП 3.1, УТ 11, КА, ERP) есть встроенный отчёт по правам. Он собирает картину «пользователь → роли → разрешённые действия» без ручного обхода профилей.

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

Отчёт показывает:

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

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

Таблица прав роли в Конфигураторе

Конфигуратор показывает права на самом нижнем уровне — по каждому объекту конфигурации. Это способ для тех, кто настраивает роли или разбирается, почему типовой механизм раздаёт права именно так.

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

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

Теперь состав самой роли. В дереве конфигурации раскройте ветку Общие → Роли, откройте нужную роль. Откроется таблица: слева — объекты конфигурации (справочники, документы, регистры), справа — права по каждому.

Основные права, которые вы увидите:

• 📖 Чтение, Добавление, Изменение, Удаление — операции с данными объекта.
• 👁 Просмотр, Редактирование, Интерактивное добавление — что можно делать в формах.
• ✅ Проведение, Отмена проведения — для документов.
• ⚙️ Административные права, Монопольный режим — для служебных ролей.

Внизу окна роли — раздел «Ограничение доступа к данным». Если там есть записи, у роли настроен RLS (разбор — ниже).

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

Заодно в Конфигураторе удобно посмотреть, кто сейчас работает в базе: меню Администрирование → Активные пользователи показывает открытые сеансы и приложения. На состав прав это не влияет, но помогает понять, под кем именно воспроизводится проблема.

Журнал регистрации: кто получил отказ в доступе

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

В режиме «1С:Предприятие» откройте Администрирование → Обслуживание → Журнал регистрации (если команды нет в меню, журнал доступен через Все функции → Стандартные → Журнал регистрации).

Настройте отбор:

1. Задайте пользователя и период.
2. В отборе по важности оставьте события уровня «Ошибка».
3. Ищите записи об отказе в доступе — в них указан объект, к которому не хватило прав.

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

Журнал отвечает на вопрос «что именно заблокировано», но не объясняет механизм. Часто причина не в отсутствии права, а в ограничении на уровне записей — поэтому после журнала смотрят RLS.

Проверка прав в коде: для разработчиков

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

Проверка права на объект:

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

Проверка назначенной роли:

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

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

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

Для RLS проверки кода мало: право на объект может быть, а конкретная запись всё равно недоступна. Это следующий раздел.

RLS: ограничения на уровне записей

RLS (Row-Level Security, ограничение доступа к данным на уровне записей) — причина самой частой путаницы. Пользователь видит, что право «Чтение» у него есть, но половина документов в списке не показывается. Так и должно быть: RLS отфильтровал записи, на которые у него нет доступа по значениям.

Где это настроено:

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

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

Как проверить, что именно ограничено:

1. В карточке группы доступа (способ 1) посмотрите закладку ограничений — там перечислены разрешённые организации, склады, контрагенты.
2. Если нужно убедиться на данных — постройте под этим пользователем отчёт или список документов и сравните с полным списком под администратором. Разница — это записи, отрезанные RLS.

Внешние обработки для массового аудита прав

Когда пользователей десятки, обходить карточки по одной бессмысленно. Тогда применяют внешнюю обработку или отчёт, который строит сводную матрицу «пользователь → объект → право» по всей базе сразу.

Такая обработка обычно:

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

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

Частые ошибки при проверке прав

Эти промахи приводят к выводу «права настроены неверно», хотя настроены они правильно — просто проверяли не там.

• 🔁 Путают роли и группы доступа. В типовой базе смотреть надо группы доступа и профили, а не искать роли в Конфигураторе. Роль — лишь кирпич, из которого собран профиль.
• 🧱 Забывают про RLS. Право на объект есть, а запись не видна из-за ограничения по организации или складу. Пока не проверите виды доступа, причину не найдёте.
• 👑 Проверяют под администратором. Под полными правами всё доступно и все записи видны. Воспроизводить проблему надо под сеансом самого пользователя.
• 🗂 Правят роли прямо в типовой конфигурации. Это снимает её с поддержки и ломает обновления. Права меняют через профили групп доступа.
• 🔕 Ждут записей в журнале, не включив протоколирование. Если журнал по отказам доступа пуст, сначала проверьте, что эти события вообще записываются.