Как программно назначить роль пользователю в 1С

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

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

Ниже разобраны оба подхода, проверка результата, типичные ошибки и ограничения, о которых нужно помнить до изменения прав в рабочей базе.

Когда программное назначение роли оправдано

Ручное назначение через конфигуратор или раздел «Администрирование» подходит для разовых операций. Программный подход выбирают, когда действия повторяются и подчиняются правилам: выгрузка пользователей из Active Directory или кадровой системы, автоматическое создание учётных записей для новых филиалов, временное выделение прав на период проекта, массовое обновление прав после изменения матрицы доступа.

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

Назначение роли через ПользователиИнформационнойБазы

Базовый сценарий для конфигурации без БСП выглядит так: найти пользователя по имени или уникальному идентификатору, добавить роль в коллекцию, записать. Код выполняется на сервере и требует права «Администрирование» у текущего сеанса.

ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("ИвановИИ");
Если ПользовательИБ = Неопределено Тогда
ВызватьИсключение "Пользователь не найден";
КонецЕсли;

РольМетаданные = Метаданные.Роли.Найти("МенеджерПоПродажам");
Если РольМетаданные = Неопределено Тогда
ВызватьИсключение "Роль не найдена в конфигурации";
КонецЕсли;

Если Не ПользовательИБ.Роли.Содержит(РольМетаданные) Тогда
ПользовательИБ.Роли.Добавить(РольМетаданные);
ПользовательИБ.Записать();
КонецЕсли;

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

Для снятия роли используется зеркальный вызов — ПользовательИБ.Роли.Удалить(РольМетаданные) с последующей записью. Полностью очистить набор ролей можно методом Роли.Очистить(), но делать это без резервной копии списка прав не стоит.

ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("ИвановИИ");
ПользовательИБ.Роли.Добавить(Метаданные.Роли.МенеджерПоПродажам);
ПользовательИБ.Записать();

Массовое назначение ролей нескольким пользователям

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

МассивИмен = Новый Массив;
МассивИмен.Добавить("ИвановИИ");
МассивИмен.Добавить("ПетроваАС");

Для Каждого ИмяПользователя Из МассивИмен Цикл
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени(ИмяПользователя);
Если ПользовательИБ = Неопределено Тогда
Продолжить;
КонецЕсли;
Если Не ПользовательИБ.Роли.Содержит(Метаданные.Роли.МенеджерПоПродажам) Тогда
ПользовательИБ.Роли.Добавить(Метаданные.Роли.МенеджерПоПродажам);
ПользовательИБ.Записать();
КонецЕсли;
КонецЦикла;

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

1. 1
   Сформируйте список пользователей (имена или GUID) и проверьте, что все они существуют в базе
2. 2
   Убедитесь, что роль существует в метаданных конфигурации
3. 3
   Выполните цикл с проверкой Роли.Содержит() и записью каждого пользователя
4. 4
   Запишите в журнал или протокол, кому роль назначена, кто пропущен
5. 5
   Проверьте результат под учётной записью одного из пользователей

Назначение прав в типовых конфигурациях на БСП

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

Правильный программный путь в БСП — найти или создать элемент справочника «Группы доступа» (или «Профили групп доступа») и включить в него пользователя через табличную часть «Пользователи». Упрощённый пример:

ГруппаСсылка = Справочники.ГруппыДоступа.НайтиПоНаименованию("Менеджеры по продажам");
ГруппаОбъект = ГруппаСсылка.ПолучитьОбъект();

НоваяСтрока = ГруппаОбъект.Пользователи.Добавить();
НоваяСтрока.Пользователь = Справочники.Пользователи.НайтиПоНаименованию("Иванов Иван");
ГруппаОбъект.Записать();

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

Проверка результата и границы безопасной работы

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

Проверить фактические права на конкретный объект помогает функция ПравоДоступа("Изменение", Метаданные.Документы.РеализацияТоваровУслуг) — она учитывает роли текущего пользователя. Для проверки другого пользователя такой штатной функции нет, поэтому надёжнее тестировать входом под его учётной записью.

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

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

Самая частая ошибка — обращение к роли по синониму вместо имени. В коде Метаданные.Роли.Найти("Менеджер по продажам") с пробелом вернёт Неопределено, потому что имя роли в метаданных не содержит пробелов. Вторая распространённая проблема — выполнение кода на клиенте: работа с пользователями информационной базы доступна только на сервере, поэтому процедуру нужно размещать в серверном контексте общего модуля или вызывать через серверный вызов.

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

Альтернативные способы управления правами

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

В крупных внедрениях на БСП вместо прямого кода используют механизм «Группы доступа» совместно с настройкой наследования прав от подразделения или должности. Это дольше в настройке, но исключает «скрытый» код, меняющий права, и упрощает аудит доступа.

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