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

· 9 мин

Содержание

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

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

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

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

  1. 🧱 Роль — объект конфигурации. В ней разработчик задал, что можно делать с каждым справочником, документом, отчётом: чтение, добавление, изменение, проведение и так далее. Роли создают в Конфигураторе, пользователь их не редактирует.
  2. 📦 Профиль группы доступа — набор ролей под должность: «Бухгалтер», «Кадровик», «Кладовщик». Это понятие библиотеки стандартных подсистем (БСП), а не платформы.
  3. 👥 Группа доступа — профиль плюс список участников и, при необходимости, ограничения: по организациям, складам, видам документов.

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

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

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

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

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

Это основной способ для бухгалтера-администратора и для 1С-ника, который работает в типовой конфигурации.

Через карточку пользователя

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

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

Через группы доступа

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

  1. В том же разделе Настройки пользователей и прав откройте «Группы доступа».
  2. Откройте группу и посмотрите вкладку участников.
  3. Учтите, что участником может быть не человек, а группа пользователей. Тогда в доступ попадают все её члены.

Упрощённая настройка прав

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

Отчёт по правам доступа: что разрешено к объекту

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

Где найти:

  • 📋 в карточке пользователя — среди отчётов, доступных из формы;
  • 📋 в разделе Администрирование → Настройки пользователей и прав — по ссылке на отчёты по правам доступа (название ссылки зависит от версии БСП).

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

  • 🔹 перечень объектов метаданных (документы, справочники, регистры) и права на каждый: чтение, добавление, изменение, интерактивная пометка удаления;
  • 🔹 через какие группы доступа и профили это право получено;
  • 🔹 есть ли ограничения на уровне записей — например, доступ только по одной организации.

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

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

Роли пользователя в Конфигураторе

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

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

Чтобы увидеть права самой роли, раскройте в дереве конфигурации ветку Общие → Роли и откройте роль. Слева — объекты, справа — права на выбранный объект. Для сравнения ролей между собой в контекстном меню ветки «Роли» есть команда «Все роли»: она показывает таблицу «объект × роль» с отметками прав.

Не меняйте роли пользователей типовой конфигурации в Конфигураторе. БСП перезапишет их по группам доступа, а до этого момента права в карточке и в платформе будут расходиться. Меняйте состав групп доступа в пользовательском режиме.

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

Запрос к группам доступа через Консоль запросов

Когда пользователей десятки, кликать по карточкам долго. Консоль запросов (внешняя обработка, есть в составе инструментов разработчика) выдаёт всё одной таблицей. Источник данных — справочники БСП, поэтому способ работает только в конфигурациях на её основе.

Запрос возвращает группы доступа, профили и роли конкретного пользователя:

ВЫБРАТЬ
    Участники.Ссылка КАК ГруппаДоступа,
    Участники.Ссылка.Профиль КАК Профиль,
    РолиПрофиля.Роль КАК Роль
ИЗ
    Справочник.ГруппыДоступа.Пользователи КАК Участники
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ПрофилиГруппДоступа.Роли КАК РолиПрофиля
        ПО Участники.Ссылка.Профиль = РолиПрофиля.Ссылка
ГДЕ
    Участники.Пользователь = &Пользователь
    И НЕ Участники.Ссылка.ПометкаУдаления
УПОРЯДОЧИТЬ ПО
    ГруппаДоступа,
    Роль

В параметр &Пользователь передайте элемент справочника «Пользователи». Чтобы получить сводку по всем сразу, уберите условие на пользователя и выведите поле Участники.Пользователь.

Два ограничения запроса:

  • 👥 если пользователь входит в группу доступа через группу пользователей, напрямую он в табличной части не найдётся — добавьте в условие его группы пользователей;
  • 🧩 запрос показывает назначенные роли, но не итоговые права с учётом RLS. Для этого нужен отчёт из предыдущего раздела.

Вход под другим пользователем для проверки

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

Рабочий порядок:

  1. Создайте тестового пользователя, например Тест_Кладовщик.
  2. Включите его в те же группы доступа, что и проверяемого сотрудника. Совпадение должно быть полным, включая ограничения по организациям.
  3. Задайте тестовому пользователю пароль.
  4. Войдите под ним и повторите действия, на которых у сотрудника ошибка.

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

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F"D:\Bases\Buh" /N"Тест_Кладовщик" /P"Пароль123"

Для серверной базы вместо /F используйте /S"имя_сервера\имя_базы".

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

Что вам нужно узнать?

Определение роли пользователя кодом и в отладчике

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

Проверка одной роли

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

Функция РольДоступна проверяет роль текущего сеанса по имени из конфигурации, а не по синониму. Имя смотрите в свойствах роли в Конфигураторе.

Список всех ролей пользователя

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

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

Проверка конкретного права

Роль — это набор прав, а часто важно само право. Для этого есть ПравоДоступа:

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

Третьим параметром можно передать роль (Метаданные.Роли.ИмяРоли) или пользователя ИБ — тогда проверяется право не текущего сеанса, а указанного объекта.

В отладчике

Поставьте точку останова там, где у пользователя возникает ошибка, запустите отладку под тестовым пользователем и вычислите в табло выражение РольДоступна("ИмяРоли") или ПривилегированныйРежим(). Второе выражение показывает, работает ли код в привилегированном режиме: в нём проверки прав не выполняются, и результат РольДоступна может ввести в заблуждение.

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

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

Ситуации, на которых чаще всего теряют время при разборе прав.

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

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

Может ли обычный пользователь сам узнать свои роли?
Как правило, нет: список ролей и групп доступа видит администратор. Пользователь замечает только последствия — недоступные разделы не показываются в интерфейсе, а при попытке действия появляется ошибка прав.
Чем роль отличается от профиля группы доступа?
Роль — объект конфигурации, её меняет только разработчик. Профиль — набор ролей, который администратор собирает и меняет в пользовательском режиме без доработки программы.
Где увидеть, кто менял права пользователя?
В журнале регистрации (Администрирование → Обслуживание → Журнал регистрации). Отберите события изменения пользователей ИБ и записи справочников «Группы доступа» и «Пользователи».
Сколько ролей может быть у одного пользователя?
Ограничения на количество нет. Пользователь получает объединение прав всех ролей, поэтому лишняя роль только расширяет доступ, но не сужает его.
Работают ли роли в файловой базе так же, как в серверной?
Да, механизм ролей и групп доступа одинаков. Разница в производительности ограничений на уровне записей: в больших серверных базах их настройка заметнее влияет на скорость.