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

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

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

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

Где хранятся роли и как они связаны с правами

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

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

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

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

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

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

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

Проверка прав в режиме «Предприятие»

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

Путь к настройкам может немного отличаться в зависимости от конфигурации и её версии: иногда это «НСИ и администрирование → Администрирование → Пользователи и права». Если раздел не виден, проверьте, что у вас самого есть роль администратора и что в настройках включено использование групп доступа.

Отчёт «Анализ прав доступа»

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

Проверка ролей программно через встроенный язык

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

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

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

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

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

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

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

Типичные ошибки и ограничения

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

Вторая ошибка — забыть, что изменения применяются после перезахода пользователя. Третья — путать роли конфигурации и права на уровне СУБД или домена: аутентификация операционной системы и права SQL-сервера к ролям 1С отношения не имеют.

Меры предосторожности при работе с ролями

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

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

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