Odoo Changelog — 2026-04-01

Wednesday, April 1, 2026

2 changes · 19.0

Improvements(2)

Enhancements to existing features

Integrate Paper muncher and modularize document generation.

Core19.0accountwebbaseHigh impact

This update replaces the hardcoded WKHTML reporting engine with a flexible, modular system that supports multiple reporting engines including a new Paper Muncher option. Companies can now choose their preferred reporting engine for different types of reports, improving flexibility and reducing dependency on a single solution.

Original PR description

Description of the issue/feature this PR addresses:
We currently force the use of WKHTML, since it's hardcoded we can't add new reporting engines easily.
The main goal of this PR is to be able to :
- modularize the reporting engines
- make accounting use the same generation pipeline
- add a new reporting engine for paper-muncher
- allow user to choose their reporting engine by company/action report/accounting report


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

#reporting#document-generation#modularization#configuration

[PERF] stock_account_report: Optimize memory usage in inventory valuation report

PR #253331

Core19.0stock_accountHigh impact

The inventory valuation report previously crashed when handling databases with 300,000+ products due to excessive memory usage. This fix optimizes how the system loads product data, reducing memory consumption by up to 67% and making the report usable for large-scale operations. The report now successfully handles massive product catalogs without errors or system slowdowns.

Original PR description

Behavior before:
Opening the inventory valuation report on databases with 300k+ products
(storable) caused an out-of-memory (OOM) error, making the report completely
unusable at this scale.

Behavior after:
The inventory valuation report loads successfully and efficiently for 300k+
products without any memory errors or RAM spikes.

Root Cause:
In `_get_accounts_by_product()`, querying all storable products creates a massive
recordset. When iterating through this recordset, the call to `_get_product_accounts()`
accesses various relational and property fields (like categories and accounts).
Because standard ORM prefetching was active, accessing these relational fields on the
first loop iteration triggered a massive batch-fetch for all 300k+ products in the
recordset simultaneously. This cascading prefetch overloaded the environment cache
and caused an immediate OOM crash.

Fix:
Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`.
This disables the greedy batch-loading behavior across the entire recordset. The ORM
now fetches the required relational accounting fields surgically, record-by-record
inside the loop, maintaining a minimal memory footprint and preventing the crash.

Benchmark:

| Products Count | Memory Before  | Memory After | Time Before | Time After |
|------------------------|-------------------------|----------------------|------------------- |----------------|
| 300k+                  | Memory Error     | 1.1. GB             | 46.63 s           | 1.9 m         |
| 200k                    | Memory Error     | 566.4 MB         | 1.2 m              | 1 m            |
| 100k                    | 873.1 MB             | 286.8 MB         | 36.74 s            | 32.15 s      |
| 50k                      | 442.1 MB             | 145.6 MB         | 18.96 s            | 17.65 s      |

opw-5462037



Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Description of the issue/feature this PR addresses: We currently force the use of WKHTML, since it's hardcoded we can't add new reporting engines easily. The main goal of this PR is to be able to : - modularize the reporting engines - make accounting use the same generation pipeline - add a new reporting engine for paper-muncher - allow user to choose their reporting engine by company/action report/accounting report --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Behavior before: Opening the inventory valuation report on databases with 300k+ products (storable) caused an out-of-memory (OOM) error, making the report completely unusable at this scale. Behavior after: The inventory valuation report loads successfully and efficiently for 300k+ products without any memory errors or RAM spikes. Root Cause: In `_get_accounts_by_product()`, querying all storable products creates a massive recordset. When iterating through this recordset, the call to `_get_product_accounts()` accesses various relational and property fields (like categories and accounts). Because standard ORM prefetching was active, accessing these relational fields on the first loop iteration triggered a massive batch-fetch for all 300k+ products in the recordset simultaneously. This cascading prefetch overloaded the environment cache and caused an immediate OOM crash. Fix: Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`. This disables the greedy batch-loading behavior across the entire recordset. The ORM now fetches the required relational accounting fields surgically, record-by-record inside the loop, maintaining a minimal memory footprint and preventing the crash. Benchmark: | Products Count | Memory Before | Memory After | Time Before | Time After | |------------------------|-------------------------|----------------------|------------------- |----------------| | 300k+ | Memory Error | 1.1. GB | 46.63 s | 1.9 m | | 200k | Memory Error | 566.4 MB | 1.2 m | 1 m | | 100k | 873.1 MB | 286.8 MB | 36.74 s | 32.15 s | | 50k | 442.1 MB | 145.6 MB | 18.96 s | 17.65 s | opw-5462037 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr