Wednesday, September 16, 2026
9 changes · 17.0
Enhancements to existing features
This update ensures that changes to related records made through background context commands follow the same permission rules as normal field updates. It prevents unauthorized actions from being silently skipped, making access behavior more consistent and predictable for users.
Original PR description
Some commands may perform a change on related records by using Commands. When passed through the context, unallowed actions are ignored instead of rising access errors. This check aligns the behaviour with normal writes of fields. A test in `project` module shows this behaviour. Backport of odoo/odoo#258845 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288162
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-prFixes French Flow 10 e-reporting so purchase documents, tax details, VAT cases, and field values are generated in the format expected by the French public platform. Rejected reports now show the reason to users and can be corrected and resent, reducing blocked compliance submissions and manual investigation.
Original PR description
Flow 10 reports could be rejected because purchase document type codes were reversed, generated values did not always respect PPF constraints, and tax summaries could contain unsupported or…
Flow 10 reports could be rejected because purchase document type codes were reversed, generated values did not always respect PPF constraints, and tax summaries could contain unsupported or inconsistent data. Moreover, PPF responses were stored without being processed. Rejected reports therefore remained marked as sent, while users could neither see the rejection reason nor correct and resend them properly. Correct the document type mapping, constrain and validate generated values, fix tax data generation, and process PPF responses. Rejected reports now expose their reasons in the chatter and can be corrected and manually resent while preserving previous payloads. This PR backports the following 18.0+ fixes to 17.0: - [Correct Flow 10 invoice type codes](https://github.com/odoo/odoo/pull/286526) - [Validate Flow 10 report values](https://github.com/odoo/odoo/pull/286536) - [Correct Flow 10 tax data](https://github.com/odoo/odoo/pull/286547) - [Process Flow 10 PPF responses](https://github.com/odoo/odoo/pull/287338) - [Exclude OSS VAT from Flow 10](https://github.com/odoo/odoo/pull/288013) Only the changes required for 17.0 compatibility were made, mainly adapting translation calls, reporting scope checks, and test APIs. No Task ID
This 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
The accounting prediction logic now uses the most recent past entries instead of older records. This helps ensure suggested accounting values are based on relevant recent activity, improving reliability for users.
Original PR description
This commit: https://github.com/odoo/enterprise/pull/38830/changes#diff-6f6931855e0903ff0d3f2b39bd5703ceaef9bdf9a516862b83f38d2d5b21a232 change the order of the predictive queries, removing the sorting order by date. Based on the current docstring: https://github.com/odoo/enterprise/blob/66682012145e5116ebec0183102bc5e930c2c343/account_accountant/models/account_move.py#L676 this is not correct, as we expect to retrieve the previous 100 entries, rather than the oldest ones. Correcting the query order ensures that the most recent entries are considered for predictive purposes. opw-6558929
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
Theme updates now correctly remove website-specific copies and related inherited views when a theme view is deleted. This prevents update failures and helps keep website themes maintainable when theme data changes.
Original PR description
When a record disappears from a theme's data files, updating that theme deletes its per-website copies. The context built for `copy_ids` in `_process_end_unlink_record` used the literal `'MODULE_UNINSTALL_FLAG'` instead of the constant, and passed it as a positional dict, which replaces the whole context rather than extending it. `ir.ui.view.unlink` therefore did not cascade to the inheriting views and the `inherit_id` foreign key refused the deletion, aborting the theme update. Reported by: https://github.com/odoo/odoo/issues/286171
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
This fix ensures purchase order notification templates are updated properly during upgrades instead of being locked as non-updatable data. It helps prevent rendering errors when migrated databases process purchase order line changes, such as price-only updates.
Original PR description
In this commit: https://github.com/odoo/odoo/commit/eadf1270ed515424aeffcc713ca39d193b9ed6f1 the `track_po_line_template` template was added in a `noupdate` file. The commit specifies: “put their…
In this commit: https://github.com/odoo/odoo/commit/eadf1270ed515424aeffcc713ca39d193b9ed6f1 the `track_po_line_template` template was added in a `noupdate` file. The commit specifies: “put their declaration in no update when not done if template has no technical code or complex dependency on underlying code;” However, this is not actually the case for the two templates in this file. This did not cause any error in v17, but errors started appearing later because of https://github.com/odoo/odoo/pull/254602, which modified this code and the related Python code, leading to an error when no product quantity is changed. Steps to reproduce in a 19.3 database migrated from v19: - Create a purchase order with one product line and confirm it. - Only change the unit price of that line. - Error: "Error rendering template: ..." While this can also be considered a migration issue, I think the simpler and more logical solution is to remove the noupdate from this file. Also, this targets v17 to avoid the same potential error in this file in the future. opw-6518729