Почему после обновления 1С:Бухгалтерии 3.0 слетают права пользователей и как это исправить?

Нередко после очередного обновления конфигурации «1С:Бухгалтерия предприятия 3.0» администраторы сталкиваются с неприятной ситуацией: у пользователей пропадают выданные ранее права, слетают роли или перестают работать группы доступа. Приходится заново настраивать доступ вручную. Выясним причину такого поведения подсистемы управления доступом и разберем по шагам, как настроить систему так, чтобы права оставались неизменными после любых обновлений.

Причина 1. Назначение ролей напрямую пользователю в обход механизмов БСП

Проанализируем базовый принцип, заложенный в Библиотеку стандартных подсистем (БСП). В типовых конфигурациях состав действующих ролей пользователя информационной базы жестко синхронизируется со справочниками ГруппыДоступа и ПрофилиГруппДоступа.

Если администратор открывает список пользователей через конфигуратор или через меню Функции для технического специалиста и выставляет роли флажками непосредственно в карточке пользователя ИБ, система запоминает эту конфигурацию лишь временно. При первом же обновлении конфигурации или запуске процедур обновления информационной базы БСП выполняет регламентную сверку:

1. Система вычисляет результирующий набор ролей, исходя из назначенных пользователю групп доступа.
2. Все роли, назначенные пользователю напрямую и отсутствующие в его профилях, определяются как лишние.
3. БСП принудительно перезаписывает пользователя информационной базы, удаляя все прямые назначения.

Решение: Никогда не назначаем роли пользователям напрямую через конфигуратор или технический справочник пользователей. Все права выдаются исключительно через создание групп доступа и привязку к ним соответствующих профилей.

Причина 2. Модификация поставляемых профилей групп доступа

Поставляемые профили (такие как «Бухгалтер», «Главный бухгалтер», «Менеджер по продажам») являются частью типовой конфигурации. Их состав ролей жестко описан в программном коде БСП. При обновлении конфигурации выполняется процедура приведения поставляемых профилей к типовому описанию из метаданных. Все добавленные вручную роли из поставляемого профиля автоматически удаляются, а удаленные типовые роли возвращаются обратно.

Разберем по шагам правильный алгоритм создания собственных прав:

1. Открываем раздел Администрирование — Настройки пользователей и прав — Профили групп доступа.
2. Находим типовой профиль, который требуется изменить, и создаем его копию (по кнопке Скопировать).
3. Задаем новому профилю понятное наименование (например, «Бухгалтер (дополнительный)»).
4. Отмечаем флажками необходимые роли или снимаем лишние. Созданный вручную профиль не является поставляемым, и процедура обновления БСП его не затрагивает.
5. Создаем новую группу доступа, привязываем к ней созданный пользовательский профиль и включаем в нее целевых пользователей.

Причина 3. Особенности работы с ролями из расширений конфигурации

Если дополнительные роли добавлены через расширение конфигурации, механизм БСП может терять их по следующим причинам:

1. Отключение расширения платформой при обновлении: Если в свойствах расширения параметр Действие при несоответствии версии установлен в значение Отключать, при изменении версии конфигурации платформа деактивирует расширение. На этапе обновления вспомогательных данных БСП не находит ролей расширения в метаданных и очищает их из профилей или помечает как недоступные (знаком вопроса). Чтобы этого избежать, установим в свойствах расширения значение Предупреждать.
2. Синхронизация идентификаторов метаданных: Роли в профилях БСП хранятся через ссылки на справочники ИдентификаторыОбъектовМетаданных и ИдентификаторыОбъектовРасширений. После добавления новых ролей в расширение необходимо убедиться, что идентификаторы успешно обновились до назначения ролей пользователям.
3. Ограничения для пользователей с полными правами: В механизмах БСП заложена проверка администраторов: если пользователю назначен профиль с административными правами (роль ПолныеПрава), алгоритм при обновлении очищает у него все прочие нестандартные роли, если их имена не оканчиваются на служебные суффиксы БСП. Не следует назначать роли расширения пользователям с полными правами — такие роли предназначены для обычных пользователей.

Штатная программная поставка профилей из расширения

Рассмотрим продвинутый способ: если разрабатывается тиражное расширение, состав профилей можно поставлять программно. Для этого в расширении переопределяется модуль УправлениеДоступомПереопределяемый и процедура ПриЗаполненииСпискаПоставляемыхПрофилейГруппДоступа.

Посмотрим на пример программного описания поставляемого профиля в расширении:

Процедура ПриЗаполненииСпискаПоставляемыхПрофилейГруппДоступа(ОписанияПрофилей) Экспорт
    
    Описание = ОписанияПрофилей.Добавить();
    Описание.Имя = "Расш_ДополнительныеПраваБухгалтера";
    Описание.Наименование = НСтр("ru = 'Дополнительные права бухгалтера (расширение)'");
    Описание.Идентификатор = Новый УникальныйИдентификатор("11111111-2222-3333-4444-555555555555");
    
    // Добавление ролей в профиль
    Описание.Роли.Добавить("Расш_ЧтениеДополнительныхДокументов");
    Описание.Роли.Добавить("Расш_ИзменениеДополнительныхДокументов");
    
КонецПроцедуры

В этом случае профиль регистрируется как поставляемый самим расширением. При обновлении конфигурации подсистема БСП автоматически обновит состав ролей в соответствии с кодом расширения, не затирая пользовательские назначения.

Контроль фоновых заданий после обновления

После завершения обновления конфигурации не спешите сразу проверять права под обычными пользователями. Современные версии БСП выполняют расчет ограничений доступа (RLS) и обновление вспомогательных данных в фоновом режиме через отложенные обработчики обновления. Обязательно откроем обработку Результаты обновления программы в разделе администрирования и убедимся, что все фоновые процедуры и регламентные задания успешно завершены.