Как в 1С проверить автора бизнес-процесса и сравнить ссылку на пользователя со строкой?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

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

Прямое решение задачи: обращение к наименованию элемента

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

Посмотрим на пример базовой реализации условия:


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

В данном случае платформа неявно считывает объект из базы данных, получает строку из поля Наименование справочника Пользователи и сравнивает ее с указанным литералом.

Почему сравнение по наименованию не рекомендуется (Hardcode)

Проанализируем риски и проблемы, с которыми можно столкнуться при использовании такого подхода в реальных проектах:

  1. Неуникальность данных: Поле Наименование в справочнике пользователей не гарантирует абсолютной уникальности. В организации могут появиться полные тезки.
  2. Человеческий фактор: При смене фамилии сотрудника, исправлении опечатки в карточке пользователя или изменении формата отображения ФИО (например, с «Иванов И. И.» на «Иванов Иван Иванович») условие перестанет выполняться без каких-либо явных ошибок в коде.
  3. Снижение производительности: Обращение через точку от ссылки вида БизнесПроцесс.Автор.Наименование вызывает неявный запрос к СУБД. При обработке большого массива записей или выполнении кода в циклах это создает существенную паразитную нагрузку на сервер баз данных.
  4. Нарушение стандартов разработки: Привязка бизнес-логики к конкретным персоналиям прямо в программном коде считается антипаттерном.

Корректные способы проверки пользователей и альтернативы

Рассмотрим подробнее стандартные и надежные подходы к решению подобных задач в экосистеме 1С:Предприятие.

1. Проверка текущего пользователя сеанса

Если цель проверки — определить, является ли текущий пользователь автором бизнес-процесса, сравнение должно производиться исключительно по ссылке, без использования строковых представлений:

Вариант с использованием Библиотеки Стандартных Подсистем (БСП):


Если БизнесПроцесс.Автор = Пользователи.ТекущийПользователь() Тогда
    // Действия для автора процесса
КонецЕсли;

Вариант через параметры сеанса:


Если БизнесПроцесс.Автор = ПараметрыСеанса.ТекущийПользователь Тогда
    // Пользователь совпадает с текущим пользователем сеанса
КонецЕсли;

Вариант на чистой платформе: сопоставление уникального идентификатора пользователя информационной базы через реквизит ИдентификаторПользователяИБ ссылки с текущим пользователем платформы:


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

2. Использование ролевой модели и прав доступа

Если условие должно давать определенные привилегии или запускать специализированную ветку логики, правильнее проверять не конкретную личность, а наличие назначенной роли или права:


Если РольДоступна("СогласованиеБизнесПроцессов") Тогда
    // Логика для уполномоченного сотрудника
КонецЕсли;

3. Использование настроек, констант и групп пользователей

Чтобы исключить изменение конфигурации при смене ответственных лиц, параметры проверки следует выносить в пользовательский режим:

  1. Константы и регистры сведений: Создается константа ОтветственныйПоБизнесПроцессам с типом СправочникСсылка.Пользователи. Проверка будет выглядеть следующим образом:
    
    Если БизнесПроцесс.Автор = Константы.ОтветственныйПоБизнесПроцессам.Получить() Тогда
        // Пользователь является назначенным ответственным
    КонецЕсли;
    
  2. Группы пользователей: Если логика распространяется на группу сотрудников, создается элемент в справочнике ГруппыПользователей, а в коде проверяется вхождение ссылки автора в состав этой группы.

4. Использование уникального идентификатора (GUID)

Если в исключительной ситуации требуется зафиксировать конкретного пользователя в коде без риска изменения наименования, используют поиск по уникальному идентификатору (GUID):


ИдентификаторПользователя = Новый УникальныйИдентификатор("e1cib/data/00000000-0000-0000-0000-000000000000");
НужныйПользователь = Справочники.Пользователи.ПолучитьСсылку(ИдентификаторПользователя);

Если БизнесПроцесс.Автор = НужныйПользователь Тогда
    // Ссылки совпадают
КонецЕсли;

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

← На главную