Odoo Changelog — 2026-04-29

Wednesday, April 29, 2026

1 change

Bug Fixes(1)

Resolved issues and error corrections

[PERF] l10n_co_reports: fix MemoryError on Libro Diario for large DBs

Enterprise18.0l10n_co_reportsHIGH

This update resolves a critical issue where the Libro Diario report crashed on large databases due to excessive memory usage. The fix implements a more efficient, 'lazy-loading' architecture to handle large datasets, ensuring the report remains accessible and reliable. This change also ensures compliance with accounting regulations.

Original PR description

#### Root Cause
The report used a flat, single-tier architecture that loaded all matching `account.move.line` records at once.

Profiling revealed that `_dynamic_lines_generator` attempted to materialize the entire result set into memory via `dictfetchall()` without LIMIT or OFFSET.
Additionally, an `INNER JOIN` on `res_partner` excluded transactions lacking a partner, rendering the report legally non-compliant.

#### Fix
Implemented a two-tier lazy-loading architecture following the General Ledger pattern:

* **Tier 1 (`_dynamic_lines_generator`):** Groups entries by date using SQL `GROUP BY`. Returns summary lines per calendar day (max 31 lines for `this_month`).
* **Tier 2 (`_report_expand_unfoldable_line_libro_diario_day`):** Loads specific `account.move.line` records only when a day is expanded (`load_more_limit = 80`).

* Additional Changes:
- Changed `default_opening_date_filter` from `this_year` to `this_month`.
- Enabled `filter_unfold_all` and `load_more_limit` in XML.
- Switched to `LEFT JOIN res_partner` to include all economic transactions.
- Overrode `_get_domain` to remove the mandatory `partner_id` constraint.

The new architecture remains fully compliant with Articles 125-128 of Regulatory Compliance (Decreto 2649/1993).

opw-6023518

#reporting#performance#accounting#compliance

Loading the Libro Diario (Daily Journal Report) on production databases with large volumes of accounting data causes the Odoo server to crash with a MemoryError, killing the worker process and making the report completely inaccessible. #### Root Cause The report used a flat, single-tier architecture that loaded all matching `account.move.line` records at once. Profiling revealed that `_dynamic_lines_generator` attempted to materialize the entire result set into memory via `dictfetchall()` without LIMIT or OFFSET. Additionally, an `INNER JOIN` on `res_partner` excluded transactions lacking a partner, rendering the report legally non-compliant. #### Fix Implemented a two-tier lazy-loading architecture following the General Ledger pattern: * **Tier 1 (`_dynamic_lines_generator`):** Groups entries by date using SQL `GROUP BY`. Returns summary lines per calendar day (max 31 lines for `this_month`). * **Tier 2 (`_report_expand_unfoldable_line_libro_diario_day`):** Loads specific `account.move.line` records only when a day is expanded (`load_more_limit = 80`). * Additional Changes: - Changed `default_opening_date_filter` from `this_year` to `this_month`. - Enabled `filter_unfold_all` and `load_more_limit` in XML. - Switched to `LEFT JOIN res_partner` to include all economic transactions. - Overrode `_get_domain` to remove the mandatory `partner_id` constraint. The new architecture remains fully compliant with Articles 125-128 of Regulatory Compliance (Decreto 2649/1993). opw-6023518