Odoo Changelog — 2026-09-21

Monday, September 21, 2026

5 changes · 19.0

Improvements(5)

Enhancements to existing features

[PERF] stock_account: aciton_open_quants

Core19.0stock_accountMedium

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.

#performance#inventory#stock

[IMP] account: Improve account move amount due computation

PR #288894

Core19.0accountMedium

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

#invoicing#payments#amount-due#outstanding-credit

[PERF] base: cache barcode/QR PNG rendering with cache

PR #289261

Core19.0baseMedium

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

[IMP] iap: add sticky notification when IAP down

PR #289549

Core19.0iapMedium

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

#iap#notification#service availability

[PERF] website, website_sale: drop description_ecommerce from fuzzysearch

PR #289376

Core19.0websitewebsite_saleHigh impact

Website product search no longer scans long product descriptions when generating typo suggestions, while still keeping those descriptions searchable normally. This significantly speeds up shop search and autocomplete for catalogs with large eCommerce descriptions.

Original PR description

Issue --> The fuzzy search builds a list of words to suggest for typos. It runs word_similarity() over every search field with a 0.3 threshold. On `product.template` that includes…

Issue -->

The fuzzy search builds a list of words to suggest for typos. It runs word_similarity() over every search field with a 0.3 threshold. On `product.template` that includes `description_ecommerce`, which stores full HTML and can hold tens of kB per record, base64 images included.

With a long text, the 0.3 threshold matches nearly every row. No trigram index can narrow that down, so all the time goes into recomputing word_similarity on the heap. The GIN index from `index="trigram"` makes it worse: it underestimates the number of matching rows, so the planner takes a single threaded bitmap heap scan instead of a parallel seq scan.

Solution -->

Add an optional `fuzzy_search_fields` key to the search details. It falls back to `search_fields`, and `website_sale` uses it to skip description_ecommerce when enumerating words. The field stays in search_fields, so `(=)ilike` still works and still uses its GIN index.

Addionally, remove `_description_ecommerce_gist_idx`. A pg_trgm gist leaf entry holds every distinct trigram of the value, 3 bytes each. Past ~2700 distinct trigrams it goes over the 8191 byte limit for an index row and `CREATE INDEX` fails.

Benchmark -->

One word search on a reference database, 43828 products with an eCommerce description (4.5 kB on average, 68 kB at most). Median of repeated requests, responses identical before and after.

| Route                                       | Before  | After  |
|--------------------------------------------|-------|------|
| GET /shop?search=                           | 11.58 s | 0.87 s |
| POST /website/snippet/autocomplete          | 10.95 s | 0.22 s |

opw-6571788

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

### 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

Issue --> The fuzzy search builds a list of words to suggest for typos. It runs word_similarity() over every search field with a 0.3 threshold. On `product.template` that includes `description_ecommerce`, which stores full HTML and can hold tens of kB per record, base64 images included. With a long text, the 0.3 threshold matches nearly every row. No trigram index can narrow that down, so all the time goes into recomputing word_similarity on the heap. The GIN index from `index="trigram"` makes it worse: it underestimates the number of matching rows, so the planner takes a single threaded bitmap heap scan instead of a parallel seq scan. Solution --> Add an optional `fuzzy_search_fields` key to the search details. It falls back to `search_fields`, and `website_sale` uses it to skip description_ecommerce when enumerating words. The field stays in search_fields, so `(=)ilike` still works and still uses its GIN index. Addionally, remove `_description_ecommerce_gist_idx`. A pg_trgm gist leaf entry holds every distinct trigram of the value, 3 bytes each. Past ~2700 distinct trigrams it goes over the 8191 byte limit for an index row and `CREATE INDEX` fails. Benchmark --> One word search on a reference database, 43828 products with an eCommerce description (4.5 kB on average, 68 kB at most). Median of repeated requests, responses identical before and after. | Route | Before | After | |--------------------------------------------|-------|------| | GET /shop?search= | 11.58 s | 0.87 s | | POST /website/snippet/autocomplete | 10.95 s | 0.22 s | opw-6571788