Skip to content

[17.0][FIX] ptplus_partner: guard the 17.0 column rename with column_exists - #7

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

[17.0][FIX] ptplus_partner: guard the 17.0 column rename with column_exists#7
eantones wants to merge 1 commit into
17.0from
17.0-fix-ptplus_partner-migration_guards

Conversation

@eantones

@eantones eantones commented Aug 5, 2026

Copy link
Copy Markdown
Member

Replaces #4, auto-closed by GitHub at the instant the fork base 17.0 was resynced to the vendor's new snapshot (same mechanics as the sibling PR).

Same single commit, rebased clean onto snapshot ac8eba5d: ptplus_partner 17.0.4.0.2 re-renames res_partner.legal_name behind an inverted registry guard and would hit DuplicateColumn (the column exists since the 15 heal); the column_exists guard makes the rename run only when the column is absent. Local-only.

The 17.0.4.0.2 pre-migration renames res_partner.legal_name behind a
registry-membership check only (and the check is inverted relative to
when the rename is safe: at ptplus_partner's own pre-migration nothing
defines l10n_pt_legal_name yet, so the guard always fires). On databases
where the target column already exists, 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, and use the 'not in' comparison form. Same fix as the
16.0 scripts (16.0.4.0.1/16.0.4.0.2).
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