Как быстро вернуть неизмененные объекты конфигурации 1С на полную поддержку?

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

В этой статье мы подробно разберем, как решить эту задачу быстро, безопасно и профессионально. Мы изучим штатные инструменты платформы 1С, проанализируем риски прямого вмешательства в базу данных на уровне SQL и рассмотрим альтернативные современные методы, включая выгрузку конфигурации в файлы XML.

Почему не стоит пытаться решить задачу напрямую через SQL?

На первый взгляд кажется заманчивым написать простой SQL-скрипт к таблице Config, который бы мгновенно обновил признаки поддержки для нужных объектов. Давайте детально разберем, почему этот путь является крайне опасным и технически сложным:

1. Сложная структура хранения данных. В СУБД правила поддержки не лежат в виде простой плоской таблицы формата «Имя Объекта — Статус Поддержки». Вся конфигурация, включая правила поддержки, хранится в таблице Config (или ConfigSave для конфигурации базы данных) в поле BinaryData.
2. Использование бинарных файлов. Связи и правила поддержки зашиты в двоичных файлах внутри СУБД. Например, настройки хранятся в файле родительских конфигураций ParentConfigurations.bin, ссылка на который определяется через чтение служебной записи root в таблице Config и последующий поиск по уникальным идентификаторам GUID.
3. Сжатие и сериализация данных. Данные в поле BinaryData сжаты по алгоритму zlib (RFC 1950) и сериализованы во внутренний проприетарный формат 1С. Чтобы изменить правила поддержки через SQL, вам пришлось бы извлекать blob-данные, распаковывать их, парсить структуру связей GUID объектов с правилами поддержки, вносить изменения, упаковывать обратно в zlib и записывать в базу. Любая микроошибка в этом процессе приведет к полной неработоспособности конфигурации.

Поэтому мы настоятельно рекомендуем отказаться от манипуляций на уровне СУБД и использовать надежные штатные механизмы платформы.

Способ 1. Использование фильтра в окне сравнения и объединения (Штатный лайфхак)

Самый быстрый и безопасный способ вернуть неизмененные объекты на поддержку «в три клика» прямо в Конфигураторе — это использование механизма сравнения с конфигурацией поставщика. Проанализируем этот алгоритм по шагам:

1. Откроем Конфигуратор нашей рабочей базы данных.
2. Перейдем в меню Конфигурация — Поддержка — Настройка поддержки.
3. В открывшемся окне нажмем кнопку Сравнить, объединить. Платформа запустит процесс сопоставления нашей конфигурации с оригинальной конфигурацией поставщика.
4. В открывшемся окне сравнения установим специальный фильтр. Для этого найдем поле фильтрации в нижней или верхней части окна и выберем режим: «Показывать только совпадающие объекты» (или «Не измененные»).
5. После применения фильтра в дереве сравнения останутся исключительно те объекты метаданных, которые не подвергались изменениям с нашей стороны.
6. Встанем на корневой элемент дерева метаданных (самая верхняя строчка с названием конфигурации).
7. Нажмем кнопку «Изменить режим объединения/поддержки» (кнопка «Изменить» в колонке режима поддержки).
8. В появившемся диалоговом окне установим режим «Объект поставщика не редактируется» (это и есть возвращение «замочка») и обязательно установим флаг «Установить для подчиненных объектов».

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

Способ 2. Метод «Чистой базы» (Полная замена через файл конфигурации)

Если в вашей рабочей базе снято с поддержки огромное количество объектов, а реально измененных — единицы, наиболее надежным и чистым методом будет полная замена конфигурации через файл .cf. Давайте рассмотрим этот изящный метод:

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

Выясним, почему это работает без потери данных. Команда «Загрузить конфигурацию из файла» полностью перезаписывает структуру метаданных вместе с правилами поддержки. Поскольку физическая структура таблиц в файле .cf полностью совпадает с рабочей базой, платформа успешно применит новые правила поддержки, не затрагивая сами данные в таблицах СУБД. Все неизмененные объекты автоматически встанут под замок.

Способ 3. Альтернативный метод с использованием выгрузки в XML-файлы

Для крупных проектов, где ведется разработка с использованием систем контроля версий (Git) или среды разработки 1С:Enterprise Development Tools (EDT), отлично подойдет метод работы с исходными кодами конфигурации.

Начиная с платформы 8.3, разработчики могут выгружать и загружать конфигурацию в виде набора файлов XML. При выгрузке настройки поддержки помещаются в файлы ConfigDumpInfo.xml и ParentConfigurations.bin.

Для выполнения этой операции в пакетном режиме мы можем использовать командную строку. Рассмотрим пример команды для выгрузки конфигурации в файлы:

"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /F "C:\PutToYourBase" /N "Администратор" /P "Пароль" /DumpConfigToFiles "C:\UnpackedConfig" -Format Hierarchical

После выгрузки мы можем использовать специализированные скрипты на языке OneScript или Python, которые анализируют XML-описания объектов метаданных, находят расхождения с конфигурацией поставщика и автоматически корректируют файлы настроек поддержки. После этого измененные файлы XML загружаются обратно в базу данных с помощью команды:

"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /F "C:\PutToYourBase" /N "Администратор" /P "Пароль" /LoadConfigFromFiles "C:\UnpackedConfig"

Этот способ требует навыков автоматизации и написания скриптов, но он незаменим при организации процессов непрерывной интеграции (CI/CD) для автоматического контроля чистоты поддержки метаданных.

Подведем итоги

Мы подробно разобрали, как решать проблему массовой установки объектов на поддержку в 1С. Попытки править таблицы СУБД напрямую через SQL сопряжены с колоссальными рисками и неоправданно сложны. Вместо этого используйте штатный и элегантный лайфхак с фильтрацией совпадающих объектов в окне сравнения конфигураций или воспользуйтесь методом «чистой базы», который гарантирует идеальный порядок в правилах поддержки вашей конфигурации.