Настройка прав доступа в конфигурации 1С:Зарплата и управление персоналом 3.1 является одной из самых трудоемких задач для администратора или программиста. Часто возникает потребность ограничить видимость сотрудников так, чтобы пользователь видел только «своих» подчиненных или коллег по конкретному подразделению. Однако архитектура ЗУП накладывает свои ограничения, так как данные разделены между двумя справочниками: Сотрудники и Физические лица. В этой статье мы подробно разберем, как правильно настроить такие ограничения, рассмотрим штатные механизмы и альтернативные способы решения задачи.
Прежде чем переходить к настройке, проанализируем ситуацию. В ЗУП 3.1 справочник Сотрудники хранит информацию о трудовых отношениях (подразделение, должность, табельный номер), а справочник Физические лица содержит персональные данные (паспорт, ИНН, СНИЛС). Основная сложность заключается в том, что стандартный механизм RLS (Record Level Security) часто привязывает права доступа именно к физическому лицу. Если одно физлицо работает в разных подразделениях (внутреннее совместительство), ограничение только по «Подразделению» в справочнике сотрудников может работать некорректно. Система либо полностью скроет человека, либо откроет лишние данные.
Рассмотрим самый надежный и штатный метод, который позволяет разделить сотрудников без внесения изменений в программный код. Этот метод основан на связке пользователей и конкретных групп физлиц.
Выполним следующие шаги для настройки:
Группа доступа. Для массового заполнения рекомендуется использовать обработку Групповое изменение реквизитов.Важный нюанс: Если вы используете этот метод, помните о совместителях. Если физическое лицо занимает должности в двух разных подразделениях, доступ к нему будет определяться по совокупности прав. Это может потребовать создания комбинированных групп доступа или тщательного контроля за заполнением реквизитов.
Разберем вариант для более опытных специалистов, когда штатных групп доступа недостаточно. Мы можем изменить условия ограничения непосредственно в метаданных. Посмотрим на примере справочника СотрудникиОрганизаций (имя в метаданных для справочника Сотрудники).
В конфигураторе для каждой роли (например, «Пользователь») на уровне прав «Чтение» или «Просмотр» можно задать текст условия RLS. Рассмотрим пример логики:
#ПоЗначениям("Справочник.Сотрудники","Чтение","",
"Организации","Организация",
"Подразделения","ТекущееПодразделение",
"","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","")
Такой подход позволяет жестко ограничить выборку данных на уровне SQL-запроса. Выясним причину, почему это может не работать: если в конфигурации включен производительный режим RLS, то система использует заранее рассчитанные ключи доступа. После изменения условий RLS в конфигураторе обязательно запустите регламентное задание Обновление ключей доступа, иначе изменения не вступят в силу.
Проанализируем современный подход, который часто называют «полуштатным». Он заключается в использовании механизмов Библиотеки стандартных подсистем для динамической модификации запросов в формах списков. Это не совсем RLS, так как данные скрываются только в интерфейсе.
Суть метода заключается в перехвате события открытия формы списка. Разберем по шагам, как это реализовать через расширение:
Сотрудники.ПриСозданииНаСервере добавим программную установку фиксированного отбора по разрешенным подразделениям текущего пользователя.Пример программного кода для установки отбора:
&НаСервере
Процедура Расш_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
ЭлементОтбора = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Подразделение");
ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.ВСписке;
ЭлементОтбора.ПравоеЗначение = ПолучитьСписокРазрешенныхПодразделенийДляПользователя(ПараметрыСеанса.ТекущийПользователь);
ЭлементОтбора.Использование = Истина;
ЭлементОтбора.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;
КонецПроцедуры
Преимущество данного метода: Он работает значительно быстрее классического RLS и не создает нагрузки на базу данных при расчете прав для каждой записи. Недостаток: Если пользователь умеет пользоваться универсальными отчетами или консолью запросов, он сможет обойти это ограничение.
Рассмотрим подробнее механизм «Ключей доступа», который появился в последних версиях платформы 8.3 и ЗУП 3.1. Если вы столкнулись с ситуацией, когда пользователь добавлен в группу доступа, но все равно не видит документы (как описано в Сообщении 11 форума), причина кроется в кешировании прав.
Система хранит права в специальных вспомогательных таблицах. Проанализируем алгоритм действий при возникновении ошибок отображения:
Обновление ключей доступа.Физические лица у проблемного сотрудника заполнена именно та Группа доступа, которая указана в настройках прав пользователя.Подведем итог нашему анализу. Если ваша задача — стандартное разделение прав в рамках типовой конфигурации без программирования, используйте Способ 1 (Группы доступа физлиц). Несмотря на трудоемкость первичного заполнения реквизитов, это единственный путь, поддерживаемый вендором при обновлениях.
Если же требуется гибкое управление, например, доступ только к штатному расписанию одной организации при праве просмотра другой, стоит комбинировать Профили групп доступа с наложением ограничений по видам объектов. Помните, что в ЗУП 3.1 доступ к документам (Начисления, Больничные) часто наследуется от прав на сотрудника, поэтому правильная настройка справочника Сотрудники является фундаментом всей безопасности системы.