[18.0][FIX] ptplus_accounting: keep the taxonomy remap versioned 17.0.5.1.0#1
Open
eantones wants to merge 1 commit into
Open
[18.0][FIX] ptplus_accounting: keep the taxonomy remap versioned 17.0.5.1.0#1eantones wants to merge 1 commit into
eantones wants to merge 1 commit into
Conversation
….5.1.0 Functional release 5.1.0 replaced the account-taxonomy model (prefixes moved to l10n_pt_account_taxonomy_prefix) and ships a post-migration that remaps account.account.l10n_pt_taxonomy_id from the old rows to the new catalog. On this branch that script was published under 18.0.5.1.0 — the same byte-identical file the 17.0 branch ships as 17.0.5.1.0. It first appeared in the 2026-04-06 snapshot; the 2026-01-08 snapshot only had the correctly kept 17.0.5.0.1 pre-migration. Versioned 18.0.5.1.0 it runs AGAIN for every database coming from 17.0 (installed 17.0.5.1.0 < 18.0.5.1.0), where accounts already point at new-model rows: account_prefix reads NULL, the f-string interpolates the literal None, the (prefix, reference, code) lookup matches nothing, and the no-match branch wipes l10n_pt_taxonomy_id — erasing the SAF-T taxonomy from every mapped account. Move the script back under its original version, like the sibling 17.0.5.0.1 kept in this branch: databases jumping straight from a pre-5.1.0 series still run it once; databases that already ran it at 17.0 skip it. No content change.
eantones
force-pushed
the
18.0-fix-ptplus_accounting-taxonomy_remap_version
branch
from
July 20, 2026 09:26
d71dfcd to
5e8bc0a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 5.1.0 functional release replaced the account-taxonomy model and ships a post-migration that remaps
account.account.l10n_pt_taxonomy_idto the new catalog. On this branch the script is published under18.0.5.1.0— byte-identical to the one the 17.0 branch ships as17.0.5.1.0(snapshot timeline: absent on 2026-01-08, present since 2026-04-06).Versioned
18.0.5.1.0it re-runs for every database coming from 17.0, where the remap already happened: accounts point at new-model rows,account_prefixreads NULL, the f-string interpolates the literalNone, the(prefix, reference, code)lookup matches nothing, and the wipe-on-no-match branch erases the taxonomy. On a real 14→18 chain this erases the SAF-T taxonomy from every mapped account at the 17→18 hop (No taxonomies match foundonce per account, logger root).Fix: move the script back under its original version
17.0.5.1.0, exactly like the sibling17.0.5.0.1pre-migration already kept in this branch. Odoo's migration versioning then does the guarding natively — direct jumps from a pre-5.1.0 series still run it once; databases that already ran it at 17.0 skip it. No content change.Validation on the next full rehearsal: zero
No taxonomies match foundat 17→18 and account-taxonomy count POST == PRE.Note: the vendor mirror is bot-published with force-pushed snapshots per release — this branch must be re-parented if a new vendor snapshot lands before the final run. Same fix will be proposed to Exo.