Odoo Changelog — 2026-09-16

Wednesday, September 16, 2026

2 changes · 18.0

Bug Fixes(2)

Resolved issues and error corrections

[FIX] l10n_no_reports: deterministic eVAT code order

Enterprise18.0l10n_no_reports

Norwegian eVAT report details are now generated in a consistent order. This prevents random test failures and helps ensure the report output remains reliable and predictable.

Original PR description

The Norwegian tax report is built from ordered elements, but the summary detail per tax code is appended from a list that is quasi-directly calculated straight from PostgreSQL. The query does not request a specific result order causing indeterminism (it depends on the query plan chosen: hash vs. sort aggregate, parallel workers) when the whole XML tree is compared against a golden copy in tests.

An explicit ORDER BY clause is added to the taxes query. The chosen key is the tax_code, because these can be casted for integer natural sort. The produced XML tree can be compared in its entirety without random failures.

REF Runbot; https://runbot.odoo.com/odoo/error/939532

Forward-Port-Of: odoo/enterprise#131307

#norway#evat#tax-reporting#stability

[FIX] spreadsheet: preserve trusted markup in action help

PR #286191

Core18.0spreadsheet

This fix ensures help content opened from spreadsheets keeps its intended formatting instead of appearing as escaped text. Users will see trusted help messages rendered properly, improving clarity when navigating from spreadsheet links or actions.

Original PR description

Current behavior before PR:
- `navigateTo` cleans up the action description using `JSON.parse(JSON.stringify(...))`.
- This removes Owl's `markup()` wrapper from the `help` field.
- As a result, the trusted HTML is converted to a plain string and gets escaped instead of being rendered.

Desired behavior after PR is merged:
- Pass the action description directly to doAction.
- `_preprocessAction` already provides defensive fallbacks for individual fields,
  such as `action.domain || [] and action.display_name || action.name || "".`
- Therefore, undefined fields or missing keys are handled safely without
  the need for the JSON round-trip.
- This preserves the trusted markup in the help field
  and renders the HTML correctly.

Task: [6428217](https://www.odoo.com/odoo/project/2328/tasks/6428217)

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

#spreadsheet#help#formatting

The Norwegian tax report is built from ordered elements, but the summary detail per tax code is appended from a list that is quasi-directly calculated straight from PostgreSQL. The query does not request a specific result order causing indeterminism (it depends on the query plan chosen: hash vs. sort aggregate, parallel workers) when the whole XML tree is compared against a golden copy in tests. An explicit ORDER BY clause is added to the taxes query. The chosen key is the tax_code, because these can be casted for integer natural sort. The produced XML tree can be compared in its entirety without random failures. REF Runbot; https://runbot.odoo.com/odoo/error/939532 Forward-Port-Of: odoo/enterprise#131307

Current behavior before PR: - `navigateTo` cleans up the action description using `JSON.parse(JSON.stringify(...))`. - This removes Owl's `markup()` wrapper from the `help` field. - As a result, the trusted HTML is converted to a plain string and gets escaped instead of being rendered. Desired behavior after PR is merged: - Pass the action description directly to doAction. - `_preprocessAction` already provides defensive fallbacks for individual fields, such as `action.domain || [] and action.display_name || action.name || "".` - Therefore, undefined fields or missing keys are handled safely without the need for the JSON round-trip. - This preserves the trusted markup in the help field and renders the HTML correctly. Task: [6428217](https://www.odoo.com/odoo/project/2328/tasks/6428217) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr