Wednesday, September 23, 2026
3 changes · saas-19.4
Enhancements to existing features
This change improves the speed and reliability of accounting-related test setup by helping the system make better database decisions after loading test account data. It reduces long delays in localization test runs, helping development and validation pipelines complete much faster without changing normal user behavior.
Original PR description
The default order of account.account joins an aggregate over the ancestor paths of every account. A company created in a test only exists in the test transaction, so the planner assumes it has a…
The default order of account.account joins an aggregate over the ancestor paths of every account. A company created in a test only exists in the test transaction, so the planner assumes it has a single account and reruns that aggregate for each of its accounts, including the dead rows left by earlier test classes. On runbot this turned 5s L10n class setups into minutes and got buckets killed. Analyzing the account tables after the chart load gives the planner the real counts, as test_balance_sheet_balanced already does. Order changes alone are not enough, and rewriting the query slows down production searches. The journal default account lookup only needs a code length, so it now uses the id order. | Benchmark | without | with | |--------------------------------------------|----------|----------| | Peru TestSequence, 25k dead rows (local) | 120-132s | 4.3-7.2s | | L10n build, slow account path queries | 94 | 0 | | L10n build, TestPosAR setup | 145s | 15s | | L10n build, TestCIIFR setup | 109s | 8s | Forward-Port-Of: odoo/odoo#289782
Payroll dashboard loading and batch payslip generation have been optimized, especially for runs with many payslips and varied configurations. This should reduce waiting time for payroll teams when preparing and reviewing payroll runs.
Original PR description
Loading payslip run dashboard Before <img width="1915" height="740" alt="image" src="https://github.com/user-attachments/assets/738f75c0-1b49-4869-8375-aba6fe447588" /> After <img width="1906" height="737" alt="image" src="https://github.com/user-attachments/assets/57584776-362f-428f-b930-12581f1d12a1" /> Generating 200 payslips with various configurations Forward-Port-Of: odoo/enterprise#130000
Large reports that reuse the same barcode or QR code now avoid regenerating the same image over and over. This can dramatically reduce report generation time for long documents such as labels, invoices, or traceability reports with repeated codes.
Original PR description
### Description of the issue/feature this PR addresses: Reports with hundreds of pages and repeated barcodes or QR codes (same document number, same lot code on every page) re-run reportlab's…
### Description of the issue/feature this PR addresses: Reports with hundreds of pages and repeated barcodes or QR codes (same document number, same lot code on every page) re-run reportlab's createBarcodeDrawing and PNG encoding on every occurrence, even when type, value and options are identical. ### Current behavior before PR: Every call to ir.actions.report.barcode() re-renders the barcode/QR from scratch, regardless of whether an identical (type, value, options) combination was already rendered earlier in the same report. On a 900-page report with 4 barcodes/page, this dominates generation time. Benchmark, 900 pages x 4 barcodes/page, 4 distinct combos, 3600 calls: 19.131s. ### Desired behavior after PR is merged: The pure rendering step (createBarcodeDrawing + mask + PNG encoding) is extracted to a module-level function keyed on (barcode_type, value, options, mask) and wrapped with functools.lru_cache. Repeated barcodes reuse the cached PNG instead of re-rendering. Same benchmark after the fix: 0.020s (946.7x speedup, cache_info hits=3596 misses=4). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289742 Forward-Port-Of: odoo/odoo#289135