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