Thursday, September 4, 2025
2 changes · saas-18.3
Resolved issues and error corrections
Public-facing pages could appear blank when a standard page wrapper was missing during loading. The update uses the page body as a backup so views such as meeting room booking and kiosk setup pages load correctly.
Original PR description
**Before this PR:** The screen appears blank in places like meeting room booking view, install kiosk app page (events, attendance, rooms, frontdesk), etc. **Version:** Although this issue exists in future versions, it is fixed in the version where public interactions are introduced. **Technical reason:** The issue was introduced by this commit: https://github.com/odoo/odoo/commit/dd13994674d4ef4683f5a4d46a1f604650cfb92b Happens while loading frontend assets. Here, if `#wrapwrap` is absent in dom then interaction service is not started and returned as a null. Now we keep `body` as a fallback of `#wrapwrap`. **After this PR:** The screen will load correctly and will no longer be blank. Task-4915155 Forward-Port-Of: odoo/odoo#222033
The accounting Secure Entries wizard was optimized so it can handle very large backlogs of entries waiting to be secured. This prevents memory failures and greatly reduces loading time for companies that have accumulated many pending accounting entries.
Original PR description
Description ----------- On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be…
Description
-----------
On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be hashed.
This can lead to the processing of a large number of moves when opening the Secure Entries wizard, more specifically:
```
-> `_compute_warnings`
-> `_compute_hash_date`
-> `_compute_max_hash_date`
-> `_get_chains_to_hash`
```
While manipulating this large recordset, the ORM prefetcher will read *all* fields on the model upon the first cache miss, which usually are a lot, and some of them are quite large (label type fields).
This commit refactors the code to avoid any cache miss by fetching only what is necessary. This is achieved by:
- Use of a `_read_group` instead of 2 subsequent `groupby`
- Delegate `max` and `min` lookup to the database
- Explicitly fetch the fields that are going to be read
- Avoid the linear search into the associated statement lines for unreconciled moves
- Introduce a context key `chain_info_warnings` to skip the warnings computation of `_get_chain_info`, as it's unused for the context of `_compute_max_hash_date`.
Benchmark
---------
On a database with over 1.3M `account.move` that are pending hashing, opening the wizard for the Secure Entries took:
| | Before* | After | Improvement |
|--------------|---------|---------|-------------|
| Memory | 6.8 GiB | 700 MiB | 9.9x |
| Query Count | 26.7k | 18.5k | 1.4x |
| Timing SQL | 41.2s | 18s | 2.3x |
| Timing PY | 7.29min | 14s | 31.2x |
| Timing Total | 7.98min | 32s | 15x |
\* - benchmark was taken with unlimited memory, the request takes more than 2 GiB -> OOM killed and never completes
Reference
---------
opw-5014345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225247
Forward-Port-Of: odoo/odoo#224105