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