Как связать пользователя информационной базы со справочником Пользователи в 1С

← На главную

При разработке конфигураций на платформе 1С:Предприятие 8.2 и 8.3 часто возникает фундаментальная задача: сопоставить «технического» пользователя (который заведен в Конфигураторе) с конкретным элементом справочника Пользователи. Это необходимо для автоматической подстановки ответственного в документы, разграничения прав доступа на уровне записей (RLS) и ведения истории изменений. В этой статье мы подробно разберем, как реализовать эту связь, рассмотрим различные подходы и проанализируем их сильные и слабые стороны.

Зачем нужна связка пользователя ИБ и справочника?

Прежде чем переходить к коду, разберем архитектурную суть проблемы. В системе 1С существует два «типа» пользователей:

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

Рассмотрим по шагам, как настроить их взаимодействие.

Решение 1: Синхронизация по полному имени (простой способ)

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


// Получаем имя текущего пользователя, под которым совершен вход в систему
ИмяАвторизации = ПолноеИмяПользователя(); 

Если ПустаяСтрока(ИмяАвторизации) Тогда
    ИмяАвторизации = "Пользователь не определен";
КонецЕсли;

// Пытаемся найти пользователя в справочнике по наименованию
СсылкаНаПользователя = Справочники.Пользователи.НайтиПоНаименованию(ИмяАвторизации);

// Если не нашли — создаем новый элемент (автоматическая регистрация)
Если СсылкаНаПользователя.Пустая() Тогда
    НовыйПользователь = Справочники.Пользователи.СоздатьЭлемент();
    НовыйПользователь.Наименование = ИмяАвторизации;
    // Можно заполнить дополнительные реквизиты по умолчанию
    НовыйПользователь.Записать();
    СсылкаНаПользователя = НовыйПользователь.Ссылка;
    Сообщить("Зарегистрирован новый пользователь справочника: " + ИмяАвторизации);
КонецЕсли;

Важный нюанс: Этот метод опирается на Наименование. Если администратор изменит полное имя пользователя в Конфигураторе или ФИО в справочнике, связь разорвется. Мы рекомендуем использовать этот метод только в том случае, если вы гарантируете неизменность имен.

Решение 2: Связка через уникальный идентификатор (UUID)

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


// Получаем объект текущего пользователя информационной базы
ТекущийПользовательИБ = ПользователиИнформационнойБазы.ТекущийПользователь();
// Получаем его уникальный идентификатор в виде строки
ТекИдентификатор = Строка(ТекущийПользовательИБ.УникальныйИдентификатор);

// Ищем элемент справочника по реквизиту
СпрПользователи = Справочники.Пользователи.НайтиПоРеквизиту("ИдентификаторПользователяИБ", ТекИдентификатор);

Если СпрПользователи.Пустая() Тогда
    // Обработка ситуации, когда связь еще не установлена
    // Например, можно вывести форму сопоставления или создать запись
КонецЕсли;

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

Решение 3: Использование параметров сеанса и Модуля сеанса

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

Важно помнить, что инициализацию следует делать не в интерфейсных модулях, а в Модуле сеанса, в обработчике УстановкаПараметровСеанса. Это позволит параметру быть доступным даже в фоновых заданиях.


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

Теперь в любом месте конфигурации (например, в процедуре ПередЗаписью документа) мы можем просто написать: Ответственный = ПараметрыСеанса.ТекущийПользователь;. Это работает мгновенно, так как значение уже закэшировано в сеансе.

Решение 4: Интеграция с доменной авторизацией (Active Directory)

Посмотрим на ситуацию, когда в компании используется Windows-авторизация. В этом случае 1С автоматически подхватывает учетную запись ОС. Чтобы автоматизировать связку, мы можем использовать свойство ПользовательОС. В справочнике Пользователи полезно хранить строку с доменным именем сотрудника. При первом входе система выполнит сопоставление через функцию ИмяПользователяОС(), что исключит ошибки ручного ввода ФИО.

Связь с механизмом ограничений доступа (RLS)

Разберем, зачем на самом деле нужна эта сложная механика, помимо удобства заполнения реквизитов. Основная роль справочника пользователей — работа механизма Row Level Security (RLS). Когда мы хотим, чтобы «Менеджер видел только свои заказы», платформа выполняет SQL-запрос с фильтрацией. В шаблоне ограничения доступа указывается обращение к параметру сеанса:

ГДЕ Ответственный = &ТекущийПользователь

Без корректно настроенной связи между логином входа и объектом в базе данных реализовать динамическое разграничение прав практически невозможно. Для проверки итогов учета и выявления расхождений после настройки новых прав доступа или переноса данных используется автоматическая сверка бухгалтерских и налоговых проводок.

Практические рекомендации по обслуживанию

Проанализировав опыт эксплуатации крупных систем, выделим несколько правил «хорошего тона»:

Не удаляйте пользователей: Если сотрудник уволился, не удаляйте элемент из справочника, иначе в старых документах поле «Ответственный» станет объектом «Объект не найден». Используйте флаг Недействителен.
Разделение прав: Создание элементов справочника Пользователи лучше доверять программному коду или администратору, чтобы избежать дублей, когда один и тот же человек заведен под разными именами.
Использование БСП: Если вы разрабатываете современную конфигурацию, настоятельно рекомендуем использовать Библиотеку стандартных подсистем (БСП). Подсистема «Пользователи» в БСП уже содержит все описанные выше механизмы, включая обработку UUID, работу с параметрами сеанса и формы управления правами.

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