В современных конфигурациях 1С, построенных на базе Библиотеки стандартных подсистем (БСП), к которым относится и 1С:Зарплата и управление персоналом 3.0, механизм управления правами доступа значительно усложнился по сравнению со старыми редакциями. Часто администраторы и разработчики сталкиваются с ситуацией: роль в конфигураторе создана и назначена, но в режиме «1С:Предприятие» пользователь не получает ожидаемых прав. Рассмотрим подробнее, почему это происходит и как правильно организовать работу с правами, чтобы обычные пользователи (администраторы системы) могли самостоятельно управлять доступом.
Для начала проанализируем ситуацию: почему прямое назначение роли пользователю в Конфигураторе или программное добавление роли через объект ПользовательИнформационнойБазы часто не дает результата? Дело в том, что в ЗУП 3.0 реализован многоуровневый механизм управления доступом. Права рассчитываются на основе связки нескольких объектов:
Если мы просто добавляем роль пользователю в обход этой цепочки, система БСП при очередной синхронизации данных или проверке прав может просто «затереть» эти изменения или игнорировать их, так как они отсутствуют в её внутреннем реестре групп доступа.
Проанализируем основные причины, по которым изменения в составе ролей не вступают в силу немедленно:
1. Очередь пересчета прав. В ЗУП 3.0 включено ограничение прав на уровне записей (RLS). Любое изменение состава ролей или групп доступа инициирует фоновое задание по пересчету прав. Пока это задание не выполнится, пользователь будет работать со старым набором разрешений.
2. Использование механизмов БСП. Система ожидает, что управление будет вестись через интерфейс «Администрирование — Настройки пользователей и прав». Если вы создали новую роль в расширении или основной конфигурации, её сначала нужно включить в Профиль групп доступа, а затем назначить этот профиль пользователю через Группу доступа.
3. Кэширование вспомогательных данных. БСП хранит информацию о ролях в специальных служебных справочниках, таких как ИдентификаторыОбъектовМетаданных. Если справочник не обновлен, система «не видит» новую роль в интерфейсе настройки профилей.
Рассмотрим, как правильно добавить новую роль и сделать так, чтобы пользователи могли управлять ею самостоятельно.
Если роль была создана в Конфигураторе недавно, она может не появиться в списке доступных ролей при редактировании профиля. Для принудительного обновления выполним следующий код (например, через консоль кода или внешнюю обработку):
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника();
Этот метод просканирует метаданные конфигурации и добавит новые объекты в справочник, что позволит выбирать их в интерфейсе настройки прав.
Вместо того чтобы назначать роль напрямую пользователю, создадим логическую единицу управления:
Теперь создадим связь между пользователем и профилем:
После записи группы доступа система автоматически запустит механизм обновления прав для указанных пользователей.
Посмотрим на ситуацию, когда все настройки выполнены верно, но права всё равно не работают. Скорее всего, «застряло» фоновое задание. В ЗУП 3.0 нет одного явного регламентного задания с названием «Обновление прав», но есть комплекс механизмов БСП.
Проанализируем состояние очереди обновлений. Перейдите в: Администрирование — Обслуживание — Регламентные операции — Управление пересчетом прав.
В открывшемся окне можно увидеть количество заданий в очереди. Если вы видите, что очередь не уменьшается, проверьте работу регламентных заданий в целом. Особенно важно задание «Заполнение данных для ограничения доступа». Если оно завершается с ошибкой, права обновляться не будут.
Для того чтобы не-программист мог управлять правами других пользователей, ему не обязательно давать полные права (роль ПолныеПрава). В ЗУП 3.0 предусмотрены специальные типовые профили:
Назначив пользователю профиль «Управление доступом», вы дадите ему возможность самостоятельно оперировать теми ролями, которые вы заранее включили в разрешенные профили групп доступа.
Если права ведут себя необъяснимым образом (например, роль включена, но объекты не видны), можно попробовать инициировать полный пересчет всей системы безопасности. Для этого:
Это заставит систему заново пересчитать все записи в регистрах Таблицы групп доступа, Значения групп доступа и Права ролей. Будьте осторожны: в крупных базах этот процесс может занять значительное время и потребовать монопольного доступа или значительных ресурсов сервера.
Таким образом, для корректной работы прав в ЗУП 3.0 необходимо придерживаться методики БСП: регистрировать роли в Профилях, назначать их через Группы доступа и следить за выполнением фоновых заданий по управлению пересчетом прав.