Skip to content

[15.0][OU-FIX] apriori merges/renames + pending OCA fixes for the 14→15 hop#3

Closed
eantones wants to merge 16 commits into
15.0from
15.0-apriori-merges
Closed

[15.0][OU-FIX] apriori merges/renames + pending OCA fixes for the 14→15 hop#3
eantones wants to merge 16 commits into
15.0from
15.0-apriori-merges

Conversation

@eantones

@eantones eantones commented Jun 29, 2026

Copy link
Copy Markdown
Member

Consolidated engine patches for the 14→15 hop (merged via refs/pull/3/head in the hop's repos.yaml).

Own apriori entries:

  • [OU-ADD] stock_putaway_method: Merged into stock_putaway_hook
  • [OU-ADD] queue_job_context: Merged into queue_job

Cherry-picked verbatim from open OCA PRs (authorship preserved):

product_sale_tax_price_included is an OCA module that basically provide the new native feature 'tax_string', on product models.
https://github.com/OCA/product-attribute/tree/12.0/product_sale_tax_price_included#product-sale-tax-price-included
@eantones eantones changed the title [15.0][OU-ADD] apriori: merges [15.0][OU-ADD] apriori: module renames and merges Jun 29, 2026
…_included-merged-into-account-SLG

[ADD] product_sale_tax_price_included: merged into 'account'.
@eantones eantones changed the title [15.0][OU-ADD] apriori: module renames and merges [15.0][OU-FIX] apriori merges/renames + pending OCA fixes for the 14→15 hop Jul 5, 2026
eantones and others added 5 commits July 5, 2026 18:54
stock_putaway_method (OCA/stock-logistics-warehouse) was deprecated in
15.0 and replaced by stock_putaway_hook (OCA/stock-logistics-workflow).
The migration PR OCA/stock-logistics-warehouse#1545 was closed with the
comment "Deprecated. Replaced by stock_putaway_hook" by an OCA member.

Without this entry, upgrading from 14.0 to 15.0 leaves
stock_putaway_method as an orphaned installed module in ir_module_module.
queue_job_context (OCA/queue) exists in 14.0 but was removed in 15.0; its context-key feature is provided natively by the queue_job base module from 16.0 (queue_job._job_prepare_context_before_enqueue_keys). The 15.0 migration PR OCA/queue#725 was closed with the note "not needed in v16+".

Upstream OpenUpgrade only records the merge in the 16.0 apriori, so upgrading from 14.0 to 15.0 leaves queue_job_context as an orphaned installed module in ir_module_module. Add the entry to 15.0 so it is merged into queue_job at the hop where it disappears.
fix the value of several fields on account.move and account.move.line
records linked to hr.expense records.

Co-authored-by: Miquel Raïch <miquel.raich@forgeflow.com>
fiscalyear_lock_date check prevent modifying old move, but some field
should be recomputed to be correct in 15.0.
@eantones eantones force-pushed the 15.0-apriori-merges branch from 91dcfbd to db27252 Compare July 5, 2026 16:55
eantones added 9 commits July 6, 2026 09:59
…recompute

The payment_state rework picked from OCA#4577 rebuilt _fill_payment_state
keeping only the fiscalyear_lock_date bypass, dropping the reconciliation
bypass that 4ac3a16 had introduced for the same _compute_amount() pass.
On databases where a reconciled expense move's recomputed amount_total
disagrees with its stored line balances, the recompute fires
_inverse_amount_total -> write() on reconciled lines -> UserError, aborting
the whole 14->15 upgrade. Restore the upstream-merged double bypass.
The 15.0.5.0.0 vendor upgrade adds this stored computed field on
account.move.line. On a large database the ORM's column-creation mass
compute ("Storing computed values") loads millions of rows into the
cache on top of ~300 modules' worth of upgrade state and the process is
OOM-killed. Pre-creating the column in a pre-migration makes _auto_init
skip the mass init (the openupgradelib.add_fields mechanism); the field
is recomputed in controlled batches at the target version.
The 15.0.5.0.0 vendor upgrade adds this stored computed field on
stock.picking. Same mass-compute OOM as ptplus_accounting's
l10n_pt_account_expected_balance: pre-creating the column makes the ORM
skip the whole-table init; the field is recomputed in controlled batches
at the target version.
…te before rename

Databases that already carry l10n_pt_vat_adjustment_norm_id alongside the
old vat_adjustment_norm_id duplicate crash the module's own pre-migration:
its openupgrade.rename_fields() finds the target column already present.
Drop the old duplicate first, guarded to abort if it holds any data.
The pre-00- basename makes it run before the module's own pre-migration.py
(same-version stage scripts execute in basename order).
…balance

Fill the field pre-created empty by pre-migration.py, in memory-safe chunks
using the model's own compute via the ORM (add_to_compute + flush), so the
vendor's real compute logic runs without ever reading the packaged code.
Runs in post-migration at 15.0.5.0.0, so the field is created AND filled
within this same hop — no cross-version dependency, each hop self-contained.
Fill the field pre-created empty by pre-migration.py, in memory-safe chunks
using the model's own compute via the ORM (add_to_compute + flush), so the
vendor's real compute logic runs without ever reading the packaged code.
Runs in post-migration at 15.0.5.0.0, so the field is created AND filled
within this same hop — no cross-version dependency, each hop self-contained.
…onciliation bypass

The double-bypass approach (4ac3a16, restored in 00451f1) lets the bare
_compute_amount() call fire _inverse_amount_total through Field.__set__ ->
write(): on reconciled 2-line expense moves whose recomputed amount_total
is 0, the inverse rewrites both lines' debit/credit to zero — silent data
corruption on reconciled entries (caught by a pre/post CSV audit: 828
mutated lines on a real 14.0 database). The reconciliation check that
4ac3a16 disables was the guard refusing exactly that write.

Run the compute under env.protecting() instead: assignments land in the
cache, flush() persists them by SQL, the inverse never fires, and no
lock-date or reconciliation check is triggered — so the fiscalyear bypass
and the reconciliation bypass both become unnecessary. Amounts follow the
lines, never the other way around.
@openupgrade.migrate() wraps the script in a savepoint: a cr.commit() per
chunk destroys it (RELEASE SAVEPOINT crashes on script exit, aborting the
whole upgrade at the finish line) and breaks per-module transactionality.
Memory stays bounded by the per-chunk cache invalidation alone; the
recompute measured ~3 minutes for 2.28M rows.
Same savepoint/transactionality fix as ptplus_accounting: the decorator
wraps the script in a savepoint that a mid-loop commit destroys. Cache
invalidation per chunk alone keeps memory bounded.
@eantones

Copy link
Copy Markdown
Member Author

Superseded — split into three disjoint PRs on a freshly synced 15.0 base (content verified identical to this PR, original authorship preserved):

The two upstream-of-base commits that showed here (OCA PR 5742 pair) are gone: the fork's 15.0 was fast-forwarded to OCA's tip (a7ddf23). repos.yaml v15 now wires the three branches instead of refs/pull/3/head. Closing without merge; the head branch 15.0-apriori-merges will be deleted.

@eantones eantones closed this Jul 12, 2026
@eantones eantones deleted the 15.0-apriori-merges branch July 12, 2026 20:11
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.

6 participants