При разработке алгоритмов проверки прав или автозаполнения документов в конфигурации «1С:Управление торговлей», редакция 10.3 часто возникает необходимость узнать, к какому подразделению относится текущий пользователь. Рассмотрим подробно, где эти данные хранятся в системе, как их найти в интерфейсе и какими способами корректно организовать логику проверок в коде.
В типовой конфигурации УТ 10.3 между справочником Пользователи и справочником Подразделения нет прямой кадровой привязки на уровне реквизитов. Справочник Пользователи предназначен для аутентификации и административного назначения прав, тогда как Подразделения отражает структуру организации.
Единственное типовое место, где пересекаются пользователь и подразделение — это регистр сведений Настройки пользователей. Поле «Основное подразделение» там служит значением по умолчанию для автоподстановки в создаваемые реквизиты документов, а не жестким кадровым закреплением.
Проанализируем путь в режиме «1С:Предприятие», по которому можно посмотреть или изменить подразделение для подстановки по умолчанию:
Подразделения.Данная настройка сохраняется в регистре сведений НастройкиПользователей с измерением Пользователь и характеристикой ОсновноеПодразделение из плана видов характеристик ПраваИНастройкиПользователей.
Если для бизнес-логики достаточно использовать значение автоподстановки по умолчанию, разберем, как прочитать его из кода. Для этого обратимся к типовой функции или к регистру сведений НастройкиПользователей:
// Получение значения настройки для текущего пользователя
ТекущееПодразделение = НастройкиПользователей.ПолучитьЗначениеНастройки(
ПланыВидовХарактеристик.ПраваИНастройкиПользователей.ОсновноеПодразделение
);
Если ЗначениеЗаполнено(ТекущееПодразделение) Тогда
// Выполняем необходимое условие
Если ТекущееПодразделение = ИскомоеПодразделение Тогда
// Логика для конкретного подразделения
КонецЕсли;
КонецЕсли;
Важно учесть, что пользователь может самостоятельно поменять настройки подстановки через интерфейс, если его права не ограничены. По этой причине использовать «Основное подразделение» из настроек для жестких проверок доступа (например, «Если относится к подразделению N, то запретить редактирование») небезопасно. Рассмотрим альтернативные и более надежные варианты решения этой задачи.
1. Использование справочника «Группы пользователей» (Без изменения конфигурации)
Выясним, как привязать права через группы. В справочнике ГруппыПользователей создаются группы, соответствующие подразделениям (например, «Отдел продаж», «Склад»). Пользователи распределяются по этим группам администратором, а в коде выполняется проверка вхождения текущего пользователя в группу.
2. Использование механизма свойств и категорий
Для справочника Пользователи добавляется дополнительное свойство с типом значений СправочникСсылка.Подразделения. Значение заполняется администратором в регистре сведений ЗначенияСвойствОбъектов. Пользователь не сможет изменить это значение самостоятельно без соответствующих прав.
3. Добавление отдельного регистра сведений (Минимальная доработка)
Создадим независимый регистр сведений (например, ПодразделенияПользователей) с измерением Пользователь и ресурсом Подразделение. Права на запись в данный регистр предоставляются только администраторам. В таком случае проверка в коде выполняется простым запросом или считыванием среза последних:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПодразделенияПользователей.Подразделение КАК Подразделение
|ИЗ
| РегистрСведений.ПодразделенияПользователей КАК ПодразделенияПользователей
|ГДЕ
| ПодразделенияПользователей.Пользователь = &ТекущийПользователь";
Запрос.УстановитьПараметр("ТекущийПользователь", ПараметрыСеанса.ТекущийПользователь);
РезультатЗапроса = Запрос.Выполнить();
Выбор конкретного метода зависит от требований к безопасности: если задача носит рекомендательный характер, достаточно типовой настройки по умолчанию; если же требуется жесткое разграничение прав — следует использовать группы пользователей или собственный регистр сведений.