Wednesday, September 2, 2026
6 changes · 17.0
Enhancements to existing features
Peppol messages now show a warning if they share the same unique identifier, helping businesses spot data issues that should not happen. Duplicated messages will no longer keep the original identifier, reducing the risk of confusion or processing problems.
Original PR description
This improvement adds a warning when Peppol messages share the same UUID, which should not occur. The fix also removes the copy of the UUID on duplicated messages, as the UUID must remain unique. opw-5937044
Resolved issues and error corrections
The documentation for temporary records has been corrected to match how access rights actually work today. This reduces confusion for teams configuring permissions, without changing product behavior.
Original PR description
Since 6d8688bb124d, TransientModel records use the regular access rights mechanisms instead of being implicitly restricted to their creator. The docstring was not updated with that change and has therefore incorrectly documented creator-only access since 14.0.
This fix ensures a Peppol partner validation date is stored using the correct date format from the start. It prevents upgrades from mistakenly detecting a change and running unnecessary recalculations on existing records.
Original PR description
`account_peppol_validity_last_check` is a Date field, but its column_type was initially created as `timestamp` during auto_init. The super() call later corrects the column type according to the field definition which is [date]( https://github.com/odoo/odoo/blob/8661cb5cc639b820a19e8496f276a962c67c7e3e/odoo/fields.py#L2146) This becomes an issue during upgrades when `account_peppol` is installed. The temporary column type change makes the field appear modified and can trigger an unnecessary recomputation on existing records [update_db](https://github.com/odoo/odoo/blob/8661cb5cc639b820a19e8496f276a962c67c7e3e/odoo/models.py#L3182) Initialize the column with the correct `Date` type to avoid the unnecessary recomputation during the upgrade.
Odoo's DHL REST shipping integration no longer automatically requests a carrier pickup when arranging deliveries. This removes an extra scheduling step, avoids DHL errors from incomplete pickup details, and makes DHL behave more consistently with other shipping carriers.
Original PR description
Before this commit, the DHL REST module had the pick-up request set, which led to an unnatural use flow, needing to set up an scheduled date for pick-up, and several errors from DHL when these were not properly configured. This feature was unique to this module among the shipping carriers as we don't normally request pick-up for packages and leave it to user to decide how to do it. This commit removes the request for pick up and the logic that was needed to make it work. This will make the behavior consistent with other carriers in Odoo, and avoids the need to set scheduled pick-up windows and having to deal with unnecessary errors. opw-6148927
Spreadsheet data loading now handles failed batches more efficiently by retrying smaller groups instead of every request one by one. This reduces delays and lowers the chance of overloading the server when only a few requests in a large batch fail.
Original PR description
## Description of the issue/feature this PR addresses: Previously, when a batch RPC failed, the system retried each request individually. This resulted in N sequential RPC calls, causing performance…
## Description of the issue/feature this PR addresses: Previously, when a batch RPC failed, the system retried each request individually. This resulted in N sequential RPC calls, causing performance issues for large batches and increasing the risk of rate limiting (HTTP 429) or backend overload. This commit replaces the one-by-one retry strategy with a binary split (divide and conquer) approach. When a batch fails, it is recursively split into two halves and retried independently until either the batch succeeds or only one request remains. This approach improves performance in common scenarios where only a few requests fail. Instead of retrying all requests individually, only the failing subsets are further split and retried. Complexity: - Best case: O(1) when the full batch succeeds - Worst case: 2N - 1 calls when all requests fail Although the worst-case number of calls is higher than in the previous approach (N), in practice, it is rare for all requests to fail. This approach performs better in typical scenarios where only a small no of requests fail. Task: [6113607](https://www.odoo.com/odoo/project/2328/tasks/6113607) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where Adyen payment information could be read from the wrong place in the payment notification payload. It helps ensure payment updates are processed with the correct details, reducing the risk of incorrect transaction handling.
Original PR description
opw-6512723