При написании условий в коде конфигураций 1С разработчики часто сталкиваются с задачей проверки авторства документа, задачи или бизнес-процесса. Если реквизит Автор имеет тип СправочникСсылка.Пользователи, попытка напрямую сравнить его со строковым значением (например, с ФИО) всегда будет возвращать Ложь, так как сравниваются значения разных типов данных.
Разберем, как технически реализовать такое сравнение, выясним, почему жесткое указание строк в коде является плохой практикой, и рассмотрим архитектурно правильные альтернативы.
Для того чтобы сопоставить строковое значение с данными пользователя, необходимо обратиться к строковому реквизиту ссылки — свойству Наименование.
Посмотрим на пример базовой реализации условия:
Если БизнесПроцесс.Автор.Наименование = "Непомнящий Алексей Геннадьевич" Тогда
Сообщить("Ты Алексей");
Иначе
Сообщить("Ты НЕ Алексей");
КонецЕсли;
В данном случае платформа неявно считывает объект из базы данных, получает строку из поля Наименование справочника Пользователи и сравнивает ее с указанным литералом.
Проанализируем риски и проблемы, с которыми можно столкнуться при использовании такого подхода в реальных проектах:
Наименование в справочнике пользователей не гарантирует абсолютной уникальности. В организации могут появиться полные тезки.БизнесПроцесс.Автор.Наименование вызывает неявный запрос к СУБД. При обработке большого массива записей или выполнении кода в циклах это создает существенную паразитную нагрузку на сервер баз данных.Рассмотрим подробнее стандартные и надежные подходы к решению подобных задач в экосистеме 1С:Предприятие.
Если цель проверки — определить, является ли текущий пользователь автором бизнес-процесса, сравнение должно производиться исключительно по ссылке, без использования строковых представлений:
Вариант с использованием Библиотеки Стандартных Подсистем (БСП):
Если БизнесПроцесс.Автор = Пользователи.ТекущийПользователь() Тогда
// Действия для автора процесса
КонецЕсли;
Вариант через параметры сеанса:
Если БизнесПроцесс.Автор = ПараметрыСеанса.ТекущийПользователь Тогда
// Пользователь совпадает с текущим пользователем сеанса
КонецЕсли;
Вариант на чистой платформе: сопоставление уникального идентификатора пользователя информационной базы через реквизит ИдентификаторПользователяИБ ссылки с текущим пользователем платформы:
ТекущийПользовательИБ = ПользователиИнформационнойБазы.ТекущийПользователь();
Если БизнесПроцесс.Автор.ИдентификаторПользователяИБ = ТекущийПользовательИБ.УникальныйИдентификатор Тогда
// Автор совпадает с текущим пользователем ИБ
КонецЕсли;
Если условие должно давать определенные привилегии или запускать специализированную ветку логики, правильнее проверять не конкретную личность, а наличие назначенной роли или права:
Если РольДоступна("СогласованиеБизнесПроцессов") Тогда
// Логика для уполномоченного сотрудника
КонецЕсли;
Чтобы исключить изменение конфигурации при смене ответственных лиц, параметры проверки следует выносить в пользовательский режим:
ОтветственныйПоБизнесПроцессам с типом СправочникСсылка.Пользователи. Проверка будет выглядеть следующим образом:
Если БизнесПроцесс.Автор = Константы.ОтветственныйПоБизнесПроцессам.Получить() Тогда
// Пользователь является назначенным ответственным
КонецЕсли;
ГруппыПользователей, а в коде проверяется вхождение ссылки автора в состав этой группы.Если в исключительной ситуации требуется зафиксировать конкретного пользователя в коде без риска изменения наименования, используют поиск по уникальному идентификатору (GUID):
ИдентификаторПользователя = Новый УникальныйИдентификатор("e1cib/data/00000000-0000-0000-0000-000000000000");
НужныйПользователь = Справочники.Пользователи.ПолучитьСсылку(ИдентификаторПользователя);
Если БизнесПроцесс.Автор = НужныйПользователь Тогда
// Ссылки совпадают
КонецЕсли;
Таким образом, для быстрого разового тестирования достаточно обратиться к свойству .Наименование, однако для продуктивной эксплуатации следует использовать сравнение по ссылке, параметры сеанса или ролевую модель.