Задача копирования пользователей между информационными базами 1С только на первый взгляд кажется простой. На практике разработчик сталкивается с необходимостью синхронизации не только имен, но и паролей, прав доступа (ролей), а также специфических объектов Библиотеки стандартных подсистем (БСП), таких как элементы справочников и групп доступа. В этой статье мы подробно разберем, как реализовать механизм переноса пользователей, используя различные подходы: от классического COM-соединения до современных HTTP-сервисов и встроенных механизмов БСП.
Прежде чем приступать к коду, проанализируем структуру хранения данных о пользователях в современных конфигурациях. В системе 1С существует два уровня сущностей:
Если мы просто создадим запись в справочнике, пользователь не сможет зайти в систему. Если создадим только ПИБ — система выдаст ошибку при попытке работы с объектами, требующими ссылку на справочник. Нам необходимо синхронизировать оба уровня.
Рассмотрим сценарий, когда из одной базы (база-источник) нам нужно программно создать пользователя в другой базе (база-приемник). Для этого удобно использовать COM-соединение. Выясним, как это реализовать по шагам.
Сначала установим соединение с целевой базой:
ПараметрыСоединения = "Srvr=""ServerName"";Ref=""TargetDB"";Usr=""Admin"";Pwd=""Password"";";
Connector = Новый COMОбъект("V83.COMConnector");
Соединение = Connector.Connect(ПараметрыСоединения);
Теперь разберем процесс создания самого пользователя. Важным моментом, упомянутым в обсуждении, является перенос пароля. Чтобы пользователю не пришлось задавать новый пароль, мы можем перенести его хеш через свойство СохраняемоеЗначениеПароля.
Пример функции для создания пользователя ИБ через COM:
Процедура СоздатьПользователяВПриемнике(ДанныеИсточника)
// ДанныеИсточника - это структура с ФИО, Именем, Ролями и Хешем пароля
НовыйПользовательИБ = Соединение.ПользователиИнформационнойБазы.СоздатьПользователя();
НовыйПользовательИБ.Имя = ДанныеИсточника.Имя;
НовыйПользовательИБ.ПолноеИмя = ДанныеИсточника.ПолноеИмя;
// Переносим хеш пароля, чтобы сохранить оригинальный пароль
НовыйПользовательИБ.СохраняемоеЗначениеПароля = ДанныеИсточника.ХешПароля;
// Добавляем роли (важно: роли должны называться одинаково в обеих базах)
Для Каждого РольИзСписка Из ДанныеИсточника.Роли Цикл
НовыйПользовательИБ.Роли.Добавить(Соединение.Метаданные.Роли.Найти(РольИзСписка));
КонецЦикла;
НовыйПользовательИБ.Записать();
КонецПроцедуры
Если конфигурации построены на БСП, часто рекомендуют использовать Конвертацию данных. Однако здесь есть существенный нюанс, который мы должны проанализировать: режим записи. По умолчанию КД записывает данные в режиме ОбменДанными.Загрузка = Истина. Это отключает проверку заполнения и, что критично, обработчики БСП, которые создают связанные записи в регистрах сведений.
Чтобы обойти это ограничение, в обработчике "После загрузки" правила обмена для справочника Пользователи следует явно указать:
Объект.ОбменДанными.Загрузка = Ложь;
Объект.Записать();
Это заставит систему выполнить все необходимые проверки и программные действия, предусмотренные разработчиками конфигурации при создании нового сотрудника.
Как справедливо отмечено в обсуждении, простого переноса ролей недостаточно для полноценной работы в современных базах. В БСП права назначаются через Группы доступа и Профили групп доступа. Рассмотрим, как решить эту задачу.
При переносе пользователя нам необходимо:
ПрофильГруппДоступа по наименованию или уникальному идентификатору (UUID).ГруппыДоступа, включив в него созданного пользователя.UUID пользователя в справочнике совпадал в обеих базах для исключения дублей при последующих обменах.В современных реалиях (использование Linux-серверов, облачных инфраструктур) использование COM-соединения может быть нестабильным или невозможным. Проанализируем альтернативу — создание HTTP-сервиса в базе-приемнике.
Преимущества этого метода:
Механика проста: база-источник отправляет POST-запрос с JSON-пакетом, содержащим все реквизиты пользователя. База-приемник принимает запрос, парсит JSON и программно создает пользователя штатными средствами своей конфигурации.
Разберем важный технический момент: если в организации используется Active Directory, процесс копирования значительно упрощается. Нам не нужно передавать СохраняемоеЗначениеПароля. Вместо этого необходимо передать свойство ПользовательОС (например, "DOMAIN\Ivanov.I").
Также стоит обратить внимание на технологию OpenID Connect. Начиная с версии платформы 8.3.14, можно настроить одну базу как провайдер аутентификации. В этом случае физическое копирование паролей вообще не требуется — пользователи авторизуются через центральную базу, а в периферийных достаточно иметь лишь запись с соответствующим именем.
При использовании универсальной обработки "Выгрузка и загрузка данных XML" (Сообщение 9) данные переносятся "как есть". Посмотрим, к чему это может привести: например, если сопоставляемые справочники в базах заводились вручную и имеют несовпадающие ссылки, стандартный обмен создаст дубли, поэтому для точечной миграции с сопоставлением по произвольным полям поиска задействуют обработку для переноса данных между похожими конфигурациями 1С.
СведенияОПользователях.Рекомендация: После массовой загрузки пользователей в режиме загрузки обязательно запустите обработку "Обновление информационной базы" (из состава БСП) или выполните программный вызов ПользователиИнформационнойБазы.ОбновитьДанные().
Выбор метода зависит от частоты задачи. Если это разовый перенос — достаточно Универсального обмена XML с последующей ручной донастройкой. Если же требуется регулярная синхронизация (например, создание пользователя в 10 базах одновременно по одной кнопке) — оптимальным решением будет создание собственной обработки, работающей через HTTP-сервисы или COM, которая будет учитывать специфику Профилей групп доступа БСП. Если необходимо настроить постоянный автоматический обмен по расписанию на основе готовых XML-правил, применяется программа автоматического обмена данными между базами 1С.