Odoo Changelog — 2025-10-01

Wednesday, October 1, 2025

2 changes · 19.0

Improvements(2)

Enhancements to existing features

[IMP] l10n_in: set default outstanding accounts on bank journals

Core19.0l10n_inMedium

Indian company setups now automatically get the right outstanding payment accounts on bank journals. This reduces manual configuration work and helps ensure accounting setups are complete and ready to use after chart of accounts installation or updates.

Original PR description

Before:
- By default, Odoo does not assign outstanding accounts (debit/credit) to bank journals. Users must configure them manually from within the journal.
- This often left setups incomplete, resulting in missing entries in the CoA.

After:
- For the Indian localisation, outstanding accounts are now automatically set on bank journals’ inbound and outbound manual payment methods.
- The payment accounts are applied by default during CoA loading and whenever payment method lines are recomputed, ensuring accounts remain consistent.

Explanation:
This improvement removes manual setup steps, and ensures a ready-to-use bank journal configuration with default outstanding accounts out of the box.

task-5055756

#india#localization#bank journals#accounting

[IMP] website: Introduce high-level cache for website pages

PR #94487

Enterprise19.0website_helpdeskMedium

Published website pages can now be served from a high-level cache, reducing page rendering time and database activity. The change includes safeguards so pages with dynamic or sensitive session-related content, such as sales orders, are not cached or reused incorrectly.

Original PR description

This commit introduces a high-level cache on the `website.page` model, similar to the one that existed before the `t-cache` directive was implemented in `ir.qweb`. This cache is designed to…

This commit introduces a high-level cache on the `website.page` model, similar to the one that existed before the `t-cache` directive was implemented in `ir.qweb`. This cache is designed to significantly improve performance by storing the HTML response of published pages, thereby reducing rendering time and database queries.

The management and logic for this cache are placed directly on the `website.page` model, as it is the source of the HTML response for these records. This approach makes it easy to control caching behavior through a few new, overridable methods:

-  `_allow_to_use_cache`: Determines whether a page is allowed to be served from the cache based on the current request, URL, or session. For example, a page with a `sale.order` in the session would not use the cache.

-  `_allow_cache_insertion`: Checks if the generated HTML content is eligible for caching. This is useful for preventing sensitive or dynamic content from being stored. For instance, a page with a reference to a `sale.order` would not be inserted into the cache.

-  `_post_process_response_from_cache`: A hook called after a response is retrieved from the cache. This method allows for post-processing, such as incrementing counters or modifying HTTP headers, without regenerating the entire page.

see https://github.com/odoo/odoo/pull/224487
see https://github.com/odoo/odoo/pull/88276

Before: - By default, Odoo does not assign outstanding accounts (debit/credit) to bank journals. Users must configure them manually from within the journal. - This often left setups incomplete, resulting in missing entries in the CoA. After: - For the Indian localisation, outstanding accounts are now automatically set on bank journals’ inbound and outbound manual payment methods. - The payment accounts are applied by default during CoA loading and whenever payment method lines are recomputed, ensuring accounts remain consistent. Explanation: This improvement removes manual setup steps, and ensures a ready-to-use bank journal configuration with default outstanding accounts out of the box. task-5055756

This commit introduces a high-level cache on the `website.page` model, similar to the one that existed before the `t-cache` directive was implemented in `ir.qweb`. This cache is designed to significantly improve performance by storing the HTML response of published pages, thereby reducing rendering time and database queries. The management and logic for this cache are placed directly on the `website.page` model, as it is the source of the HTML response for these records. This approach makes it easy to control caching behavior through a few new, overridable methods: - `_allow_to_use_cache`: Determines whether a page is allowed to be served from the cache based on the current request, URL, or session. For example, a page with a `sale.order` in the session would not use the cache. - `_allow_cache_insertion`: Checks if the generated HTML content is eligible for caching. This is useful for preventing sensitive or dynamic content from being stored. For instance, a page with a reference to a `sale.order` would not be inserted into the cache. - `_post_process_response_from_cache`: A hook called after a response is retrieved from the cache. This method allows for post-processing, such as incrementing counters or modifying HTTP headers, without regenerating the entire page. see https://github.com/odoo/odoo/pull/224487 see https://github.com/odoo/odoo/pull/88276