Odoo Changelog — 2026-08-27

Thursday, August 27, 2026

2 changes · 19.0

Improvements(2)

Enhancements to existing features

[IMP] l10n_ae_hr_payroll: backport overtime rules from 19.4

Enterprise19.0l10n_ae_hr_payrollhr_work_entry_attendanceMedium

The UAE payroll module now uses the latest overtime calculation rules from a newer release. This helps payroll teams calculate regular, night, and day-off overtime more consistently in version 19.0.

Original PR description

Backport overtime salary rules (OVTWD, OVTWDN, OVTOD) from 19.4 to 19.0, updating the computation logic to directly use `worked_days['<CODE>'].amount`.

Task:6469393

#payroll#overtime#UAE

[FIX] core: don't prefetch all fields for large batch

PR #253652

Core19.0coreMedium

This change reduces unnecessary data loading when Odoo processes very large sets of records. It can lower memory use and improve reliability for heavy operations such as large reports, while keeping the existing behavior for smaller workloads.

Original PR description

This pr is a prototype proposing to not always fetch all fields if we have a lot of records. The idea is that reading all (prefetch) fields **for a few record** makes sense because it will be less…

This pr is a prototype proposing to not always fetch all fields if we have a lot of records. 

The idea is that reading all (prefetch) fields **for a few record** makes sense because it will  be less expensive to make a slightly bigger request than needed that having to make multiple request to the database (due to the ping) 

In some cases, with **very large recordset**, prefetching all fields can be an issue 
- memory consumption
- putting data in cache takes some time

In this case, we can improve performances by prefething only the needed fields, but this is fragile, can vary per module installed, .... 

The idea behind this pull request is that it _could_ be less expensive to prefetch the field one by one, but for all records 

In a minimal database we have 7000 ir.model.data, lets take 5000 of them

```python
env.invalidate_all()
start = env.cr.sql_log_count
for rec in env['ir.model.data'].search([], limit=5000):
    rec.model
    rec.name
env.cr.sql_log_count - start
```

Before this change, we would have 6 queries and all fields in cache,
-> 1 for the search
-> 5 to prefetch data, 1 per 1000 id

After this change we would have 7 queries and only the model and name field in cache. 
-> 1 for the search
-> 2 to prefetch model and name on the first 1000 records
-> 4 to prefetch data of the 4000 remaining records

Note that this strategy could become slower if we need to prefetch a lot of fields, especially if some of those fields are needed in a place where the prefetch set is broken. If we have 1000 fields and read 10 records, we would go from 2 queries to 11 queries. The only additional query of the previous example is there to show the best possible case for a large recordset needing only a few fields. 

If we decide to introduce that, it could be an opt-in behaviour (using the context) on some specific reports generation that tends to have memory error.

This pr is a prototype proposing to not always fetch all fields if we have a lot of records. The idea is that reading all (prefetch) fields **for a few record** makes sense because it will be less expensive to make a slightly bigger request than needed that having to make multiple request to the database (due to the ping) In some cases, with **very large recordset**, prefetching all fields can be an issue - memory consumption - putting data in cache takes some time In this case, we can improve performances by prefething only the needed fields, but this is fragile, can vary per module installed, .... The idea behind this pull request is that it _could_ be less expensive to prefetch the field one by one, but for all records In a minimal database we have 7000 ir.model.data, lets take 5000 of them ```python env.invalidate_all() start = env.cr.sql_log_count for rec in env['ir.model.data'].search([], limit=5000): rec.model rec.name env.cr.sql_log_count - start ``` Before this change, we would have 6 queries and all fields in cache, -> 1 for the search -> 5 to prefetch data, 1 per 1000 id After this change we would have 7 queries and only the model and name field in cache. -> 1 for the search -> 2 to prefetch model and name on the first 1000 records -> 4 to prefetch data of the 4000 remaining records Note that this strategy could become slower if we need to prefetch a lot of fields, especially if some of those fields are needed in a place where the prefetch set is broken. If we have 1000 fields and read 10 records, we would go from 2 queries to 11 queries. The only additional query of the previous example is there to show the best possible case for a large recordset needing only a few fields. If we decide to introduce that, it could be an opt-in behaviour (using the context) on some specific reports generation that tends to have memory error.