← На главную

При выполнении обновления конфигурации базы данных (нажатии «синей бочки») специалисты часто сталкиваются с ситуацией, когда кнопка «Принять» остается неактивной, а в окне сообщений выводится предупреждение: «После исполнения в списке не осталось бы ни одного пользователя с административными правами». Эта ошибка является защитным механизмом платформы «1С:Предприятие 8.3», который предотвращает полную потерю доступа к управлению списком пользователей.

Особенно часто это происходит при попытке «перескочить» между глобально разными редакциями программ, например, при переходе с «1С:Комплексная автоматизация 1.1» на «1С:Комплексная автоматизация 2.4». Разберем подробно причины возникновения этой коллизии и способы её устранения.

Причина 1: Архитектурная несовместимость редакций

Рассмотрим ситуацию, описанную в теме. Пользователь пытается обновить КА 1.1 на КА 2.4 через обычное «Обновление конфигурации». Важно понимать, что редакция 1.1 построена на обычных формах, а 2.4 — на управляемых формах и совершенно ином ядре (архитектура ERP). Это фактически две разные программы.

Проанализируем, что происходит в этот момент внутри системы. При «накатывании» конфигурации 2.4 поверх 1.1 структура метаданных (таблиц) меняется радикально. Старые роли (например, ПолныеПрава) могут иметь те же имена, но их внутренние идентификаторы (UUID) в новой конфигурации другие. Платформа видит, что у текущих пользователей назначены роли, которые «исчезают» или заменяются новыми, в которых право «Администрирование» не проставлено. В итоге система считает, что после обновления в базе не останется никого, кто сможет зайти в Конфигуратор или управлять пользователями.

Причина 2: Специфика права «Администрирование» в платформе 8.3

Многие разработчики ошибочно полагают, что наличия роли ПолныеПрава достаточно. Однако для успешного принятия изменений конфигурации платформе требуется наличие хотя бы одного пользователя, у которого в свойствах роли в окне «Права» установлена галочка на специальном праве «Администрирование».

В современных конфигурациях на базе БСП (Библиотека стандартных подсистем), таких как КА 2.4, ERP 2.5 или УТ 11, это право часто вынесено в отдельную системную роль. Рассмотрим типичные названия таких ролей:

• АдминистрированиеСистемы
• АдминистраторСистемы
• СистемныйАдминистратор

Если вы просто создаете нового пользователя и даете ему «Полные права», кнопка «Принять» может остаться серой, если в метаданных новой версии конфигурации у роли ПолныеПрава снят флаг администрирования на уровне платформы.

Решение 1: Создание фиктивного администратора (Dummy User)

Попробуем метод создания «технического» пользователя. Это позволит обмануть систему контроля прав на этапе реструктуризации. Выполним следующие шаги:

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

После этого попробуем снова вызвать обновление конфигурации базы данных. Если роли были выбраны верно, кнопка «Принять» станет активной.

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

Если манипуляции с ролями не помогают из-за сильного расхождения метаданных, можно прибегнуть к радикальному, но эффективному методу. Выясним, как это работает:

Когда в списке пользователей Конфигуратора совсем нет записей, платформа отключает проверку административных прав при обновлении. Она предполагает, что база находится в «свободном» режиме, и позволит любому пользователю войти в систему после обновления, чтобы создать первого администратора.

Внимание: Этот метод следует выполнять строго на копии базы данных!

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

Решение 3: Проверка связи с элементами справочников

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

Рассмотрим подробнее: иногда платформа блокирует обновление, так как видит «битую» ссылку или несоответствие уникальных идентификаторов. В этом случае помогает временное отключение связи пользователя с данными (очистка поля «Имя пользователя» в справочнике или удаление связи в Конфигураторе).

Решение 4: Кэш и тестирование базы

Иногда ошибка является «фантомной» и вызвана некорректным состоянием кэша или таблиц регистрации конфигурации. Проанализируем технические шаги для устранения таких сбоев:

1. Выполним Тестирование и исправление (ТиИ) с включенными опциями «Проверка логической целостности» и «Реиндексация таблиц».
2. Очистим локальный кэш конфигуратора. Для этого можно запустить 1С с параметром /ClearCache или вручную удалить содержимое папок в %AppData%\1C\1cv8\.
3. Попробуем выгрузить конфигурацию в файл .cf, затем загрузить её обратно через «Сравнение и объединение», вручную отметив все роли для обновления.

Важное замечание по методике перехода

Как справедливо заметили участники обсуждения в Сообщениях 2 и 4, обновление КА 1.1 до КА 2.4 методом «наката» конфигурации — это путь, полный ошибок. Штатный переход на новую редакцию подразумевает перенос данных:

• Развертывание чистой базы КА 2.4 актуального релиза.
• Использование специализированных обработок выгрузки (обычно входят в состав дистрибутива обновления в папке \Convert).
• Загрузка остатков и документов в новую базу.

Если вы все же решили идти по пути обновления через Конфигуратор (например, для специфических целей разработки), обязательно убедитесь, что в списке ролей новой конфигурации проставлено право Администрирование хотя бы для одного объекта типа Роль, и эта роль назначена активному пользователю.

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