Участник сообщества #72
Участник сообщества #72
7 дек. 2025 г., 11:15(изменён)
Решено
0
0

Обновление объектов из пакетов компонента

Из чата сообщества

Столкнулся с проблемой, что не обновляются объекты из пакетов компонента. (Удаление объекта в админке не помогает, насколько помню, т. к. он остается в таблице "без s".) И вот, что обнаружил.

Данные об установленных пакетах хранятся здесь:

select cast(data as xml) from [(spxml_blobs)] where url = 'x-local://wt_data/inst_proc_packs.xml'

Чтобы пакеты компонента установились, нужно увеличить package_date в inst_packs.xml. Дата может быть будущая.

Чтобы объект пакета обновился, нужно выставить параметры объекта (в пакете) is_std в true или 1, а changed в false или 0. Если у объекта в базе change выставлен в true, нужно выполнить "Снять пометку о редактировании объекта" в карточке объекта (перед установкой пакета). Выставление global_settings.update_exist_package_obj в true вместо этого (перед process_custom_packs в init компонента) не помогает.

Версия 2023.2.1012

Участник сообщества
Участник сообщества7 дек. 2025 г., 13:11(изменён)
Решение

Так, минуточку! Что касается обновления из пакетов поставки при старте, то условия по package_date в inst_packs.xml и is_std + changed в обновляемом объекте - это общее место системы пакетов поставки с незапамятных времен. ЕМНИП.

Разве что-то поменялось?

Участник сообщества
Участник сообщества7 дек. 2025 г., 13:06(изменён)

Можно в component.js вызывать копию функций process_custom_packs и package_process без этой проверки. Мы пока так это обходим

Участник сообщества
Участник сообщества7 дек. 2025 г., 13:14(изменён)

А точно ли правильно обязывать клиентов свой кастом помечать is_std? Не хватает какого-нибудь флага, который позволил бы это обойти

Участник сообщества
Участник сообщества7 дек. 2025 г., 13:22(изменён)

А почему бы и нет. На сколько я понимаю идею is_std (@firsov_a_v поправь, если не) то is_std это разделение не на "коробка/кастом", а скорее на "бизнес/система" структуры данных. Бизнес данные инициализируются ОДИН раз и далее изменяются только в бизнес процессах. Системные же наоборот изменяются при накатывании новых версий, а при изменении же в бизнес процессах наоборот теряют возможность автоматического изменения.

Как-то так...

Участник сообщества
Участник сообщества7 дек. 2025 г., 13:28(изменён)

Есть много объектов с параметрами (либы, агенты и тд), которые в процессе работы могут неоднократно изменяться. В таком случае их обновление из инстпаков становится более сложным, как писали выше, и простого ci/cd уже не получится

Участник сообщества
Участник сообщества7 дек. 2025 г., 13:32(изменён)

Да, есть такое дело. 🤷‍♂️ WVars к сожалению выбивается из этой схемы. Поэтому в новой версии портала (Платформе) запланирован by design вынос wvars в отдельный справочник.

Участник сообщества
Участник сообщества7 дек. 2025 г., 13:36(изменён)

И еще поэтому в настоящее время настройки процессов, которые меняются в бизнес-процессе, для всех элементов, задействованных в приложении (либ, агентов, УД, выборок, т.п) сосредотачиваются в самом приложении его карточке. Где для их управления есть специальный штатный интерфейс.

Чтобы ответить, необходимо войти в систему