Wednesday, September 16, 2026
4 changes · 17.0
Resolved issues and error corrections
A formatting mistake in an internal export check has been corrected so the system reports the intended validation error instead of a generic crash. This helps make export-related failures clearer and easier to diagnose without changing normal user workflows.
Original PR description
The format was broken. `'{}:{}' % it` → `TypeError` instead of `AssertionError`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes the wording of a French localization setting so it accurately reflects that users may choose both e-reporting and not sending to the PPF. The change helps businesses avoid misunderstanding what the configuration option controls.
Original PR description
When we removed the pilot phase setting from the view, we changed that setting to only mean Enable e-reporting. But that's a mistake. In fact people are also choosing not to send to the PPF, so the previous sentence was still right. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures the Turkish Nilvera e-Dispatch module declares a required related inventory-accounting component directly. It prevents installation failures in some test or limited installation scenarios, improving reliability without changing day-to-day user workflows.
Original PR description
View 'l10n_tr_nilvera_edispatch.view_picking_form_inherit_l10n_tr_nilvera_edispatch' fails to install in single-module test skip auto_install because it depends on field stock.picking:country_code. That field is provided by module 'stock_account' which is not in the dependency path of the module. In normal install the module 'stock_account' is present through auto_install when both 'account' and 'stock' are installed. Adding the direct dependency on 'stock_account' is not a problem because the view crashes without it. 'stock_account' is available through the chain below. [l10n_tr_nilvera_edispatch] ──[depends]──> [stock] ──⚡[AUTOLOAD]──> [stock_account] [l10n_tr_nilvera_edispatch] ──[depends]──> [l10n_tr_nilvera] ──[depends]──> [l10n_tr] ──[depends]──> [account] ──⚡[AUTOLOAD]──> [stock_account] REF Runbot: https://runbot.odoo.com/odoo/error/946186
The Norwegian tax report now lists tax code details in a consistent order. This prevents random test failures and improves confidence that report output is stable and reliable.
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