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

Управление ролями пользователей через конфигуратор подходит для разовых операций, но в реальных проектах часто нужно назначать права автоматически: при создании пользователя из обработки, при синхронизации с Active Directory, при настройке прав по подразделениям. Встроенный язык 1С предоставляет объектную модель для работы с пользователями информационной базы, и добавление роли сводится к нескольким строкам кода.

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

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

Как устроен механизм ролей в информационной базе

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

Программный доступ к этому списку даёт менеджер ПользователиИнформационнойБазы. Он позволяет получить список всех пользователей, найти конкретного, создать нового и изменить свойства, включая коллекцию Роли. Коллекция содержит ссылки на объекты метаданных ролей, поэтому добавить можно только роль, реально существующую в конфигурации.

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

Базовый пример: добавить роль пользователю

Минимальный код выглядит так: находим пользователя по имени, проверяем, что роль ещё не назначена, добавляем её и записываем.

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

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

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

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

Метод Записать() фиксирует изменения. Без него все манипуляции с коллекцией ролей останутся только в памяти и пропадут при завершении кода.

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

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

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

Идентификатор = Новый УникальныйИдентификатор("a1b2c3d4-...");
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоУникальномуИдентификатору(Идентификатор);

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

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

Как добавить несколько ролей и как удалить роль

Коллекция Роли поддерживает добавление нескольких элементов перед одной записью — это эффективнее, чем записывать пользователя после каждой роли.

МассивРолей = Новый Массив;
МассивРолей.Добавить("ДобавлениеИзменениеДокументов");
МассивРолей.Добавить("ЧтениеДополнительныхОтчетов");

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

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

Особенности типовых конфигураций: профили групп доступа

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

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

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

Права на выполнение кода и применение изменений

Запись пользователя информационной базы требует у текущего сеанса права «Администрирование» (для отдельных операций — «Администрирование данных»). Если код выполняет обычный пользователь, вызов Записать() завершится ошибкой нарушения прав доступа.

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

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

1. 1
   Убедитесь, что роль существует в конфигурации: Метаданные.Роли.Найти("ИмяРоли")
2. 2
   Найдите пользователя через НайтиПоИмени или НайтиПоУникальномуИдентификатору
3. 3
   Проверьте, что роль ещё не назначена: Роли.Содержит(Роль)
4. 4
   Добавьте роль: Роли.Добавить(Роль) и вызовите Записать()
5. 5
   Проверьте результат чтением пользователя заново и попросите пользователя перезайти в сеанс

Проверка результата и типичные ошибки

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

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

FAQ