Odoo Changelog — 2026-09-14

Monday, September 14, 2026

2 changes · saas-18.3

Improvements(1)

Enhancements to existing features

[PERF] pos_preparation_display: avoid slow stageless-order query

Enterprisesaas-18.3pos_preparation_displayMedium

The preparation display now finds relevant orders much more efficiently when there are many point-of-sale orders in the database. This reduces slow loading times for busy POS environments without changing how users interact with the screen.

Original PR description

The preparation display filters its stageless orders by POS configuration. The `pos_config_id` domain is a non-stored related field,so it becomes an `IN (SELECT ...)` query on `pos_order`. On…

The preparation display filters its stageless orders by POS configuration. The `pos_config_id` domain is a non-stored related field,so it becomes an `IN (SELECT ...)` query on `pos_order`.

On databases with many POS orders, PostgreSQL materializes that complete subquery and rescans it for every preparation-display order. Replace it with a correlated `EXISTS`, allowing the linked POS order to be checked
through its primary key instead.

#### Speedup

Database with 2,114 preparation-display orders. Each value is the average of five calls after invalidating the Odoo ORM cache.


POS orders | Before | After (10 runs)
-- | -- | --
5,481 | 148 ms | 6.767 ms (5.334–17.292 ms)
184,904 | 292 ms | 3.680 ms (3.395–4.275 ms)
320,493 | 23.228 s | 4.437 ms (4.187–4.964 ms)
565,685 | 39.950 s | 4.342 ms (3.356–5.258 ms)

After the rewrite, execution time is effectively independent of the eligible
POS-order cardinality in this dataset.



opw-6438446

Forward-Port-Of: odoo/enterprise#128806

#performance#point-of-sale#preparation-display

Bug Fixes(1)

Resolved issues and error corrections

[FIX] sale_timesheet: prevent timesheet date range leak

PR #285928

Coresaas-18.3sale_timesheetMedium

Fixed an issue where invoicing multiple orders together could leave some timesheets unlinked if another order used a different billing period. This helps ensure invoices accurately include the right delivered timesheet work across mixed subscription and standard orders.

Original PR description

### Steps to reproduce:
- Install `sale_subscription_timesheet` module
- Create a subscription (Order A) with delivered-timesheet products and log timesheets within its current period (e.g., January)
- Create a standard order (Order B) with delivered-timesheet products and log timesheets outside of Order A's period (e.g., March)
- Select both orders and invoice them simultaneously in a single batch (uncheck 'Consolidated Billing')
> Result: Order B's invoice is created but silently fails to link its March timesheets, because they fall outside Order A's January window.

### Cause of Issue:
In `_link_timesheets_to_invoice`, the `start_date` and `end_date` parameters are overwritten inside the invoice line loop when `_get_range_dates` is called. Because these variables are never reset per iteration, the first order that yields a date range locks in that window for every subsequent invoice line in the batch. Timesheets outside this leaked window are silently ignored.

Additionally, the `_get_range_dates` hook is invoked before verifying if the invoice line actually contains timesheet products, causing it to execute on empty recordsets (e.g. invoice line notes)

### Fix:
Prevent the date range leak by preserving the original parameter state of the dates and safely ensure the extension hook is never invoked with an empty recordset.

opw-6507110

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284781

The preparation display filters its stageless orders by POS configuration. The `pos_config_id` domain is a non-stored related field,so it becomes an `IN (SELECT ...)` query on `pos_order`. On databases with many POS orders, PostgreSQL materializes that complete subquery and rescans it for every preparation-display order. Replace it with a correlated `EXISTS`, allowing the linked POS order to be checked through its primary key instead. #### Speedup Database with 2,114 preparation-display orders. Each value is the average of five calls after invalidating the Odoo ORM cache. POS orders | Before | After (10 runs) -- | -- | -- 5,481 | 148 ms | 6.767 ms (5.334–17.292 ms) 184,904 | 292 ms | 3.680 ms (3.395–4.275 ms) 320,493 | 23.228 s | 4.437 ms (4.187–4.964 ms) 565,685 | 39.950 s | 4.342 ms (3.356–5.258 ms) After the rewrite, execution time is effectively independent of the eligible POS-order cardinality in this dataset. opw-6438446 Forward-Port-Of: odoo/enterprise#128806

### Steps to reproduce: - Install `sale_subscription_timesheet` module - Create a subscription (Order A) with delivered-timesheet products and log timesheets within its current period (e.g., January) - Create a standard order (Order B) with delivered-timesheet products and log timesheets outside of Order A's period (e.g., March) - Select both orders and invoice them simultaneously in a single batch (uncheck 'Consolidated Billing') > Result: Order B's invoice is created but silently fails to link its March timesheets, because they fall outside Order A's January window. ### Cause of Issue: In `_link_timesheets_to_invoice`, the `start_date` and `end_date` parameters are overwritten inside the invoice line loop when `_get_range_dates` is called. Because these variables are never reset per iteration, the first order that yields a date range locks in that window for every subsequent invoice line in the batch. Timesheets outside this leaked window are silently ignored. Additionally, the `_get_range_dates` hook is invoked before verifying if the invoice line actually contains timesheet products, causing it to execute on empty recordsets (e.g. invoice line notes) ### Fix: Prevent the date range leak by preserving the original parameter state of the dates and safely ensure the extension hook is never invoked with an empty recordset. opw-6507110 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284781