Monday, September 21, 2026
4 changes · 19.0
Enhancements to existing features
This change improves the speed of opening stock quantity information in inventory valuation workflows. It helps users working with large databases get to the relevant stock details faster, reducing waiting time during day-to-day operations.
Original PR description
This function is slow as found on an MMC database. Running CI before custom module. Will make more formal when I can.
Invoices now show the correct amount due immediately while users are editing them, avoiding temporary mismatches with the invoice total. Applying outstanding credits also saves pending invoice changes first, preventing newly added invoice lines from disappearing.
Original PR description
Before this commit, the account.move amount due field would only update on record saving (as it depended on line_ids). This caused a temporary out of sync situation between the total and the amount due on the move form view. This commit ensures that the amount due is computed even before saving the record so that out-of-sync situation is avoided. It also solves the following bug: Repro steps: 1) Create a new invoice 2) Add a customer and save the record 3) Add some invoice lines 4) without saving, add a payment from the outstanding credit Issue: The added (unsaved) invoice lines are removed Solution: This commit forces a record save before assigning outstanding credit task-6534794
Large reports that reuse the same barcodes or QR codes now avoid recreating the same images over and over during generation. This can dramatically reduce report generation time for documents with many repeated codes, improving performance without changing report content.
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#289135
Users now receive a persistent notification when the IAP server is down. This helps them understand that related services are temporarily unavailable instead of assuming something is wrong with their setup.
Original PR description
We wanted to let the user know when the IAP server is down with a sticky notification. Task-6570098 Forward-Port-Of: odoo/odoo#288098