Skip to content

[16.0][FIX] ptplus_partner: guard 16.0 column renames with column_exists - #3

Open
eantones wants to merge 1 commit into
16.0from
16.0-fix-ptplus_partner-migration_guards
Open

[16.0][FIX] ptplus_partner: guard 16.0 column renames with column_exists#3
eantones wants to merge 1 commit into
16.0from
16.0-fix-ptplus_partner-migration_guards

Conversation

@eantones

Copy link
Copy Markdown
Member

The 16.0.4.0.1 and 16.0.4.0.2 pre-migrations rename res_bank/res_partner columns behind a registry-membership check only. On databases where the target column already exists (healed or partially-migrated DBs), rename_fields dies with DuplicateColumn and kills the whole upgrade.

Add a column_exists guard so the rename only runs when the target column is still absent. Pristine vendor installs keep the vendor behavior; DBs that already carry the column skip the rename instead of crashing.

Replaces the aggregate-time seds previously carried in our deployment config — policy: every code change is a published PR, never an aggregate-time mutation. To be reported to the vendor (Exo) as well.

Note: the vendor mirror is bot-published with force-pushed orphan snapshots per release — when exo 16.0 head moves, rebase this branch onto the new snapshot (rebase operativa).

The 16.0.4.0.1 and 16.0.4.0.2 pre-migrations rename res_bank/res_partner
columns behind a registry-membership check only. On databases where the
target column already exists (e.g. a healed or partially-migrated DB),
rename_fields dies with DuplicateColumn and kills the whole upgrade.

Add a column_exists guard so the rename only runs when the target column
is still absent. Pristine vendor installs keep the vendor behavior; DBs
that already carry the column skip the rename instead of crashing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant