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

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

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

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

Как устроены права в 1С: что именно проверять

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

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

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

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

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

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

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

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

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

Чтобы понять, что даёт конкретная роль, откройте её в дереве конфигурации (Общие → Роли) и посмотрите матрицу прав: какие объекты доступны на чтение, добавление, изменение, просмотр, интерактивное добавление. Удобно пользоваться поиском по имени объекта в окне редактирования роли.

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

Проверка профилей и групп доступа в режиме предприятия

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

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

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

Проверка ограничений RLS: почему роль есть, а данных нет

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

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

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

Программная проверка прав: запрос и функция ПравоДоступа

Для разработчиков и продвинутых администраторов есть точный способ проверить право на конкретный объект — встроенная функция ПравоДоступа(). Она возвращает Истина или Ложь для указанного права и объекта метаданных от имени текущего пользователя.

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

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

Для проверки доступа к данным с учётом RLS используют запрос с конструкцией РАЗРЕШЕННЫЕ: если запрос с этим ключевым словом возвращает меньше строк, чем без него, значит действуют ограничения на уровне записей. Это быстрый способ подтвердить, что проблема именно в RLS, а не в роли.

Типичные ошибки и риски при работе с правами

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

Как выбрать способ проверки под свою задачу

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

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