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

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

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

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

Как устроены права в 1С: роли, группы доступа и RLS

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

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

Третий уровень — ограничение доступа на уровне записей (RLS). Оно ограничивает не «какие документы вообще», а «какие конкретно строки»: например, менеджер видит только документы своей организации или своего склада. Именно RLS чаще всего становится причиной ситуации «документ есть, но пользователь его не видит».

Проверка прав через интерфейс предприятия

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

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

Дополнительно проверьте настройку «Ограничивать доступ на уровне записей» в разделе «Настройка пользователей и прав». Если она включена, права зависят ещё и от значений групп доступа: организаций, складов, подразделений, контрагентов.

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

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

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

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

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

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

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

Удобный приём — кнопка «Установить флажки для подсистем» или фильтр по объектам, если конфигурация большая. Также обратите внимание на колонку «Шаблоны ограничений»: наличие текста в ней означает, что для объекта действует RLS-ограничение.

Проверка ограничений на уровне записей (RLS)

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

Откройте карточку пользователя и перейдите по ссылке «Права доступа» или «Группы доступа». Проверьте, какие значения разрешены: организации, склады, кассы, подразделения. Если список значений пуст при включённом ограничении, пользователь не увидит ни одной записи соответствующего типа.

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

Проверка «глазами пользователя»

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

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

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

Программная проверка прав

Для разработчиков и администраторов, работающих с кодом, доступна проверка прав встроенными средствами языка. Функция проверки права доступа позволяет узнать, есть ли у текущего пользователя конкретное право на объект метаданных, не открывая конфигуратор.

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

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

Что делать, если прав не хватает

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

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

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

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