При работе с крупными типовыми конфигурациями, такими как 1С:ERP 2.4 или 1С:Комплексная автоматизация, разработчики часто сталкиваются со специфическим поведением платформы (в частности, на релизах 8.3.12.1685 и соседних), которое на первый взгляд кажется необъяснимым багом. Суть проблемы заключается в том, что объект конфигурации, находящийся на поддержке поставщика без возможности редактирования (с иконкой «замочка»), внезапно оказывается содержащим пользовательский код, который успешно передается через хранилище другим участникам разработки.
В этой статье мы подробно разберем, как возникает эта коллизия, чем она опасна для проекта и как правильно привести состояние метаданных в порядок, чтобы избежать критических ошибок при последующих обновлениях конфигурации.
Для начала проанализируем последовательность действий, которая приводит к рассинхронизации. Рассмотрим стандартный сценарий работы в распределенной среде через хранилище конфигурации:
В результате этого алгоритма в базе хранилища фиксируется новая версия самого объекта (с измененным кодом), но не фиксируется изменение корневого элемента, который хранит в себе информацию о правилах поддержки. Проанализируем ситуацию: для платформы объект считается «нередактируемым», так как корень транслирует старое правило («замок»), но физическое содержимое объекта в хранилище уже обновлено.
Проблема кроется в архитектурном разделении данных внутри хранилища 1С. Информация о правилах поддержки (так называемые «замочки») жестко привязана к корневому узлу конфигурации. В то же время, тело модуля, состав реквизитов и формы объекта хранятся в его собственных записях в таблицах хранилища.
В нормальных условиях платформа должна блокировать возможность помещения объекта, если его статус поддержки в локальной копии не совпадает со статусом в хранилище. Однако в версиях платформы 8.3.12 контроль целостности в этот момент ослаблен. Платформа видит, что объект захвачен, и позволяет зафиксировать его новую версию, игнорируя тот факт, что «разрешение» на это изменение (изменение в корне) так и не было зафиксировано официально.
На первый взгляд это может показаться удобным «лайфхаком», позволяющим менять код, не снимая объект с поддержки визуально. Однако это создает огромные риски для стабильности системы:
Поддержка — Обновить конфигурацию платформа ориентируется на правила поддержки. Если на объекте стоит «замок», механизм сравнения и объединения может просто проигнорировать ваши изменения, посчитав объект типовым. В результате все доработки будут затерты без предупреждения (окно сравнения может даже не открыться для этого объекта).ERP, хотя логика внутри модуля уже изменена. Это крайне затрудняет поиск ошибок и отладку.Если вы обнаружили в своей конфигурации объект, который изменен, но находится «на замке», необходимо выполнить следующие действия для восстановления корректной структуры хранилища. Рассмотрим алгоритм совместной работы по исправлению:
Прежде всего, необходимо обеспечить монопольный доступ к метаданным, отвечающим за эту коллизию. Выполним захват:
Теперь нам нужно сделать так, чтобы визуальное состояние объекта соответствовало его реальному статусу. Проанализируем настройки поддержки:
Конфигурация — Поддержка — Настройка поддержки.Чтобы платформа гарантированно зафиксировала необходимость обновления объекта в хранилище, внесем незначительное изменение в его тело. Например, откроем модуль объекта и добавим в конец лишний пробел или пустую строку. Это обновит метку модифицированности объекта в памяти платформы.
Это самый важный этап. Мы должны зафиксировать изменения и корня, и объекта одновременно, чтобы «связать» их состояния в базе хранилища.
После выполнения этих действий статус объекта (желтый куб без замка) станет корректным для всех пользователей хранилища. Теперь при получении обновлений другими разработчиками система будет четко понимать, что объект модифицирован, и механизмы сравнения/объединения будут работать предсказуемо.
Важное примечание: Если вы работаете на платформе ниже 8.3.15, старайтесь всегда проверять состав помещаемых объектов. Никогда не отменяйте захват корня, если вы меняли правила поддержки для каких-либо объектов внутри этой сессии работы. Только совместное помещение корня и измененных объектов гарантирует целостность вашей базы метаданных.