Saturday, August 22, 2026
6 changes · saas-19.4
Enhancements to existing features
This update simplifies how localization-specific partner identifiers are made available across Odoo. It reduces duplicate setup work for teams adding country-specific identifier rules, while keeping core tax identifier metadata available consistently.
Original PR description
When adding an l10n-only identifier metadata, you'll want to EXTENDS the `_get_all_additional_identifiers_metadata` if you want your new identifier to be displayed on the JSON additional identifiers. Before this commit, you also needed to EXTENDS `_get_all_identifiers_metadata` to make it available to globally, regardless of if it was in additional_identifers or not, for example for validation purposes, which is tedious and easy to avoid. Note that it make sense that the TIN_METADATA are always added in base module, since they describe the content of the `vat` field that is generic, and that we want to be available for all databases, regardless of which localization is installed. task-none
Resolved issues and error corrections
This update brings the embedded spreadsheet component up to its latest 19.4 version and fixes how input borders are displayed. Users should see more consistent spreadsheet editing visuals with no expected workflow changes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b48dbb3d11 [REL] 19.4.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/171df58fa3 [FIX] inputs: explicitly define border-style [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This fixes an issue where finding a customer's most recent sales order line for timesheet-related work could fail when the search criteria included list values. The change keeps the existing caching behavior while preventing invalid searches, improving reliability for sales and project workflows.
Original PR description
- Avoid converting list values in `_get_last_sol_of_customer_domain` to an invalid domain structure when computing the last sale order line of a customer. - Fix by using `str(domain)` as the cache key instead of the domain itself, while still passing the original `domain` to `search()`. This keeps the per-domain caching behavior intact and works for any domain, regardless of whether it contains list values. task-6425335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281897
The help text shown when hovering over the Sales Order Expiration field was rewritten to fix a grammar issue and make the wording more natural. This small correction improves clarity for sales users without changing any business process or functionality.
Original PR description
Steps to produce: --- - Install the Sales module. - Create a new Sales Order. - Hover over the `Expiration` field. Issue: --- - The help text of the Expiration field contains a grammatical error and the overall sentence is slightly awkward. Improve the help text to make it grammatically correct and more natural. opw-6481226 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283757 Forward-Port-Of: odoo/odoo#283187
This update fixes issues in Odoo's JSON logging so ignored fields and test-related log data are handled correctly. It also adds safeguards through tests and makes it easier to include extra log details without replacing the default configuration.
Original PR description
The JsonFormatter has two bugs - the ignore list is not working as expected - in 18.0-18.4 the 'test' key is broken This commit add tests to ensure those behavior works as expected While on it, also…
The JsonFormatter has two bugs - the ignore list is not working as expected - in 18.0-18.4 the 'test' key is broken This commit add tests to ensure those behavior works as expected While on it, also adds a `additional_record_keys` parameter to allow to specifically add keys to the default list, without having to override the whole list, and add additional default keys (exc_info and test) The previous `ignored_record_keys` default value was possible to remove by calling `JSONFormatter(ignore_record_keys=[])` The purpose was to be able to easily include all keys and ignore the default ingnore list, but this makes the additional blacklisting of a few keys more tedious, and the general usage and implementation more complex `JSONFormatter(ignore_record_keys=[*JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS, 'other key'])` To simplify the logic, **this is not the case anymore**, so to include all keys something like this would be needed `JSONFormatter(additional_record_keys=JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS)` Or an hardcoded list. Forward-Port-Of: odoo/odoo#283042 Forward-Port-Of: odoo/odoo#279049
Creating Colombian child contacts now keeps them as individuals unless a VAT number is provided. This prevents incorrect company classification and supports cleaner customer and contact records.
Original PR description
Before this change: When creating a child contact under a Colombian company from another company context, the identification type defaults to NIT. The system evaluated the child contact as a company immediately, regardless of whether a VAT number was entered, preventing proper individual contact creation. To reproduce: 1. Create a new contact and set the country to Colombia. 2. Set the identification type to NIT. 3. Leave the VAT field empty. 4. Observe that the "Is a Company" checkbox becomes checked automatically. After this change: The company computation logic explicitly verifies that a valid VAT number is present before evaluating NIT contacts as companies, allowing individual child contacts to retain their correct entity status. opw-6468848 Forward-Port-Of: odoo/enterprise#128656