Tuesday, September 22, 2026
3 changes · saas-19.3
Enhancements to existing features
Reports that reuse the same barcodes or QR codes now avoid regenerating each image repeatedly. This can greatly reduce generation time for large multi-page documents with repeated codes, improving responsiveness for users who create or print these reports.
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
Users now see a persistent notification when the IAP service is down. This makes service interruptions more visible, helping users understand why related features may not be working instead of assuming an issue with their own 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#289599 Forward-Port-Of: odoo/odoo#288098
Invoice forms now keep the amount due in sync with invoice lines before the invoice is saved, reducing confusion while editing. Applying outstanding credit also saves the invoice first, preventing newly added invoice lines from being lost.
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 Forward-Port-Of: odoo/odoo#288894