Администрирование · 10 мин
Как проверить роль пользователя в 1С 8
Как проверить роль пользователя в 1С 8: через конфигуратор, функцию РольДоступна() в коде, журнал регистрации и отчёты. Примеры кода и типичные ошибки.
Роль в 1С 8 определяет, какие объекты конфигурации доступны пользователю: справочники, документы, отчёты, команды и права на чтение, запись, удаление. Проверить роль требуется в двух типовых ситуациях: когда пользователь жалуется, что «не видит» документ или кнопку, и когда разработчик пишет код, поведение которого зависит от прав текущего сеанса. Для каждой задачи есть свой инструмент — от просмотра списка пользователей в конфигураторе до встроенной функции РольДоступна().
Важно понимать, что один пользователь может иметь несколько ролей одновременно, а итоговые права складываются как объединение: если хотя бы одна роль даёт право на объект, доступ будет разрешён. Поэтому проверка сводится не к поиску «единственной роли», а к определению полного набора назначенных ролей и их суммарного эффекта.
Ниже разобраны все рабочие способы: через интерфейс конфигуратора, через режим «1С:Предприятие», программно во встроенном языке, а также как проверить доступ к конкретному объекту и диагностировать типовые проблемы с правами.
Проверка роли через конфигуратор
Самый прямой способ увидеть, какие роли назначены пользователю, — открыть список пользователей в конфигураторе. Для этого нужны административные права на информационную базу. Откройте меню «Администрирование → Пользователи», найдите нужного пользователя в списке и откройте его карточку двойным щелчком.
В диалоге свойств пользователя перейдите на вкладку «Прочее». Здесь отображается список всех ролей конфигурации с флажками: отмеченные роли назначены пользователю. Удобно включить сортировку или воспользоваться поиском, если ролей в конфигурации много — в типовых решениях их бывают десятки.
Обратный путь тоже работает: в дереве конфигурации откройте ветку «Общие → Роли», выберите роль и через правую кнопку мыши посмотрите её состав. Чтобы понять, у кого из пользователей роль назначена, придётся пройтись по карточкам пользователей — штатного отчёта «роль → пользователи» в конфигураторе нет, эту задачу удобнее решать обработкой или в режиме предприятия.
Проверка ролей в режиме «1С:Предприятие»
В типовых конфигурациях (Бухгалтерия, Управление торговлей, Зарплата и управление персоналом и другие на БСП) роли назначаются не напрямую, а через профили групп доступа. Откройте раздел «Администрирование → Настройки пользователей и прав → Профили групп доступа», найдите профиль и посмотрите, какие роли в него входят, а затем проверьте, в какие группы доступа включён пользователь.
Там же, в карточке пользователя («Администрирование → Пользователи»), обычно доступна ссылка на отчёт о правах — он показывает сводную картину: какие роли действуют и к каким объектам дают доступ. Это самый быстрый способ ответить на вопрос «почему у сотрудника есть/нет доступа к документу» без запуска конфигуратора.
Для файловых баз и самописных конфигураций без БСП список пользователей доступен через «Администрирование → Пользователи» в режиме предприятия, если у текущего сеанса есть право администрирования. Состав ролей там отображается аналогично конфигуратору.
Программная проверка: функция РольДоступна()
Во встроенном языке 1С есть штатная функция РольДоступна(), которая возвращает Истина, если указанная роль есть у текущего пользователя сеанса. Это основной способ ветвления логики по правам:
Если РольДоступна("ПолныеПрава") Тогда
// действия, доступные только администратору
ИначеЕсли РольДоступна("МенеджерПоПродажам") Тогда
// ограниченный сценарий
КонецЕсли;
Имя роли передаётся строкой точно так, как оно задано в дереве конфигурации (свойство «Имя», не синоним). Регистр букв значения не имеет, но опечатка в имени приведёт к ошибке выполнения — поэтому имя лучше копировать из конфигуратора, а не набирать вручную.
Есть и объектный способ — через метаданные, он удобен, когда имя роли формируется динамически:
Если РольДоступна(Метаданные.Роли.ПолныеПрава) Тогда
// ...
КонецЕсли;
Если РольДоступна("ПолныеПрава") Тогда
Сообщить("У пользователя есть полные права");
Иначе
Сообщить("Полных прав нет");
КонецЕсли;Проверка доступа к конкретному объекту
Часто важнее не сама роль, а фактический доступ к объекту: может ли пользователь читать или изменять конкретный справочник или документ. Для этого служит функция ПравоДоступа():
Если ПравоДоступа("Изменение", Метаданные.Документы.РеализацияТоваровУслуг) Тогда
// пользователь может проводить и редактировать реализации
КонецЕсли;
Первый параметр — вид права строкой: Чтение, Добавление, Изменение, Удаление, Просмотр, ИнтерактивноеДобавление и другие. Такой подход надёжнее проверки роли, потому что права могут приходить из разных ролей, а ПравоДоступа() учитывает их суммарный эффект.
Для проверки доступа к конкретному объекту данных (а не виду метаданных) используется метод МенеджерДоступа или попытка чтения с обработкой исключения, но в большинстве прикладных задач достаточно пары РольДоступна() и ПравоДоступа().
Что использовать
Когда логика привязана к конкретной роли. Минус: ломается при переименовании роли и не учитывает суммарные права.
Когда важен фактический доступ к объекту независимо от того, какой ролью он дан. Рекомендуемый вариант в большинстве случаев.
Для разовой диагностики прав конкретного пользователя без изменения кода.
Диагностика: почему у пользователя нет доступа
Когда пользователь сообщает об ошибке «Нарушение прав доступа», самый информативный инструмент — журнал регистрации. Откройте его в конфигураторе («Администрирование → Журнал регистрации») или в режиме предприятия, установите отбор по событию «Доступ. Отказ в доступе» и по имени пользователя. В записи будет указано, к какому объекту и какому праву не хватило доступа — это сразу показывает, какую роль нужно добавить.
Ещё одна частая ситуация: роль назначена, но доступ не появился. Причины обычно такие: пользователь не перезапустил сеанс; в типовой конфигурации роль назначена напрямую, но действует механизм профилей групп доступа, который её перекрывает; либо на объект действует ограничение доступа на уровне записей (RLS), и проблема не в роли, а в шаблоне ограничения.
Для массовой проверки — например, у каких пользователей есть роль «ПолныеПрава» — удобно написать небольшую обработку, перебирающую ПользователиИнформационнойБазы.ПолучитьПользователей() и проверяющую Пользователь.Роли.Содержит(Метаданные.Роли.ПолныеПрава) для каждого.
Типичные ошибки и ограничения
Частая ошибка разработчиков — проверять роль там, где нужно проверять право. Если завтра права на документ дадут новой роли, код с РольДоступна() придётся переписывать, а ПравоДоступа() продолжит работать корректно. Проверку по имени роли оправданно использовать только для логики, жёстко привязанной к конкретной роли.
Вторая ошибка — забывать, что РольДоступна() вызывается на сервере и в клиентском контексте ведёт себя по-разному в зависимости от директив компиляции. В тонком клиенте функция доступна, но обращения к метаданным на клиенте ограничены — проверки прав лучше выполнять в серверных процедурах.
Также помните: наличие роли не гарантирует доступ к конкретным записям, если в конфигурации настроено ограничение доступа на уровне записей. Пользователь с нужной ролью может не видеть «чужие» документы — и это нормальное поведение, а не ошибка прав.
Частые вопросы
Как узнать, какие роли есть у текущего пользователя, программно?
Через объект ПользователиИнформационнойБазы: получите текущего пользователя методом ТекущийПользователь() и переберите коллекцию Роли, сравнивая каждый элемент с Метаданные.Роли. Для разовой проверки проще использовать РольДоступна() для конкретной роли.
Почему РольДоступна() возвращает Ложь, хотя роль назначена?
Чаще всего сеанс пользователя был запущен до назначения роли — нужен перезапуск. Также проверьте, что в коде указано имя роли, а не синоним, и что роль назначена именно этому пользователю, а не другому с похожим именем.
Чем отличается РольДоступна() от ПравоДоступа()?
РольДоступна() проверяет наличие конкретной роли у пользователя. ПравоДоступа() проверяет фактическое право (чтение, изменение и т.д.) на объект метаданных с учётом всех назначенных ролей. Для прикладной логики обычно правильнее второй вариант.
Можно ли проверить роль другого пользователя, а не текущего?
РольДоступна() работает только для текущего сеанса. Для другого пользователя получите его через ПользователиИнформационнойБазы.НайтиПоИмени() и проверьте, содержит ли его коллекция Роли нужную роль из Метаданные.Роли.
Где в типовой конфигурации посмотреть, какие роли реально действуют у пользователя?
В карточке пользователя в разделе «Администрирование → Пользователи» обычно есть отчёт о правах доступа, который показывает роли через профили групп доступа. Назначать роли напрямую в обход профилей в типовых решениях не рекомендуется.
Роль назначена, но документов всё равно не видно. Что проверить?
Проверьте, не действует ли ограничение доступа на уровне записей (RLS) — тогда пользователь видит только разрешённые шаблоном записи. Также убедитесь, что сеанс перезапущен, и посмотрите журнал регистрации на предмет отказов в доступе.
Что важно запомнить
Роли пользователя смотрят в конфигураторе («Администрирование → Пользователи») или через профили групп доступа в типовых конфигурациях. В коде используют РольДоступна() для конкретной роли и ПравоДоступа() для фактического доступа к объекту — второй способ надёжнее. Причину отказа в доступе всегда показывает журнал регистрации, а после изменения ролей сеанс нужно перезапустить.