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

Назначение ролей пользователям через конфигуратор подходит для разовых операций, но при массовом заведении сотрудников, интеграции с внешними системами или автоматизации обновлений удобнее управлять правами программно. В платформе 1С:Предприятие для этого существует объектная модель работы с пользователями информационной базы, доступная из встроенного языка.

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

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

Как устроено назначение ролей в платформе 1С

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

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

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

Базовый код: назначить роль пользователю

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

Функция УстановитьРольПользователю(ИмяПользователя, ИмяРоли) Экспорт

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

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

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

Возврат Истина;

КонецФункции

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

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

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

Массовое назначение и снятие ролей

На практике чаще требуется не единичное назначение, а пакетная операция: выдать роль группе сотрудников или, наоборот, отозвать у всех. Для этого удобно перебрать весь список пользователей информационной базы методом ПолучитьПользователей().

Процедура УбратьРольУВсех(ИмяРоли) Экспорт

РольМетаданные = Метаданные.Роли.Найти(ИмяРоли);
Если РольМетаданные = Неопределено Тогда
Возврат;
КонецЕсли;

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

КонецПроцедуры

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

1. 1
   Получите список целевых пользователей (по отбору из справочника или ПолучитьПользователей())
2. 2
   Для каждого найдите объект ПользовательИнформационнойБазы
3. 3
   Проверьте наличие роли через Роли.Содержит() и добавьте при отсутствии
4. 4
   Вызовите Записать() и зафиксируйте изменение в журнале
5. 5
   Проверьте результат на одном тестовом пользователе до запуска на всех

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

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

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

ГруппаДоступа = Справочники.ГруппыДоступа.НайтиПоНаименованию("Менеджеры по продажам");
Если Не ГруппаДоступа.Пустая() Тогда
ГруппаОбъект = ГруппаДоступа.ПолучитьОбъект();
НоваяСтрока = ГруппаОбъект.Пользователи.Добавить();
НоваяСтрока.Пользователь = ПользовательСсылка; // элемент справочника "Пользователи"
ГруппаОбъект.Записать();
КонецЕсли;

Точный состав табличных частей и API зависит от версии БСП: в актуальных версиях рекомендуется использовать программный интерфейс общего модуля УправлениеДоступом и связанных подсистем, а не прямую запись объектов. Перед внедрением сверяйтесь с кодом своей версии библиотеки.

Права, ограничения и безопасность

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

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

Отдельный риск — изменение собственных прав в активном сеансе. Изменения ролей применяются к сеансу не мгновенно: пользователю обычно требуется перезайти в систему, чтобы новый набор прав вступил в силу. Учитывайте это при проверке результата.

Проверка результата

После выполнения кода убедитесь, что роль действительно назначена. Быстрый способ — повторно прочитать пользователя и проверить состав коллекции ролей:

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

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

Типичные ошибки и как их избежать

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

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

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

FAQ