Tuesday, September 8, 2026
7 changes · 17.0
Resolved issues and error corrections
The Chilean electronic invoicing workflow now handles cases where the tax authority returns an empty status response. This prevents scheduled processing from stopping unexpectedly, helping keep invoice status checks running reliably.
Original PR description
When checking the status of a DTE, sometimes the response will have no `text`. This causes a traceback error that halts execution of the cron `cron_run_sii_workflow`. opw-6322106
Fixed a spelling mistake in the Helpdesk Auto Assignment group name. This improves clarity for users and administrators without changing how the feature works.
Original PR description
This commit fixes the typo in the "Auto Assignment" group. task-6542450
Customer payments in Mexican localization now inherit the payment method configured on the selected bank journal instead of always defaulting to electronic transfer. This helps ensure payment complements sent to the SAT reflect the correct payment method, reducing reporting errors.
Original PR description
Currently, payment way configured on a bank journal is not taken into account, payments will default to "03 Transferencia electrónica de fondos". Steps to reproduce: - Set the "Payment Way" of a bank journal to "04 Tarjeta de Crédito". - Manually create a customer payment in that journal - Look at the "Payment Way" of the payment, then send the payment complement (REP) to the SAT. Issue: The payment way is "03 Transferencia electrónica de fondos" and the REP carries FormaDePagoP="03" The one set on the journal is ignored. Analysis: We should evaluate the journal before the transferencia default so a payment inherits the payment way, and keep transferencia as the last possible value. opw-6493514
This fix makes product identifiers sent to Google Analytics match the identifiers used in Google Merchant Center feeds. This helps Google Ads correctly connect Shopping ad clicks with purchases, improving attribution and diagnostic accuracy.
Original PR description
**Issue:** When google analytics (GA) and google merchant center (GMC) are setup, Google Ads diagonistic reports that item IDs cannot be matched to Merchant Center. **Why this happens:** `order_lines_2_google_api` sets `product.barcode or product.id` for `item_id`, while `product.feed._prepare_gmc_items` defaults to `product.default_code or product.id` for the feed's `id` field. Google Ads/Analytics attribution relies on GA4's `item_id` matching GMC's `id` for the same product to connect Shopping ad clicks to purchase events. **References:** https://support.google.com/merchants/answer/6324405?sjid=15224664355638221483-NC https://support.google.com/google-ads/answer/14943675?hl=en Backport of d0bf183b053eb0133e6f7e5e04481ca07bff6bb3 opw-6443326
This change makes Odoo's automated tests more stable by preventing test-only password updates from rotating user sessions during login checks. It reduces unpredictable test failures without changing normal customer-facing behavior.
Original PR description
The test harness patches the CryptContext object to spend less time hashing to decrease total test runtime. Because the hash parameters have changed, every first login (per transaction) per user will result in a hash rotation. The session_id is also rotated when the password hash rotates. When multiple requests are sent to the server while a session rotation is underway, the session datastore holds either a valid, or expired, or logged-out user session. This is a source of indeterminism in tests that can be prevented by always returning None value for replacement hash. REF Runbot; https://runbot.odoo.com/odoo/error/242811 REF Runbot; https://runbot.odoo.com/odoo/error/233722
This fixes cases where spreadsheet version history could be rebuilt from the wrong starting point after a migration, causing corrupted spreadsheet states. Users restoring an older version are now protected from accidentally saving a broken spreadsheet snapshot.
Original PR description
…heet history Some spreadsheet can end up in a corrupted history state Original Data ⮕ no revision (XX) ⮕ Snapshot ⮕ Active Revisions and where the original data differ from the snapshot. XX: can…
…heet history Some spreadsheet can end up in a corrupted history state Original Data ⮕ no revision (XX) ⮕ Snapshot ⮕ Active Revisions and where the original data differ from the snapshot. XX: can occur after the script added https://github.com/odoo/upgrade/issues/6340. The migration script is supposed to rewrite the history of the spreadsheet when there are holes in the archived revisions continuity (eg. the history was original Data ⮕ rev **A** ⮕ rev **B** ⮕ rev **C** ⮕ snapshot ⮕ rev **D** and user deleted rev **B** for instance, the script deletes **A** and **C** and marks **D** as the very first revision). Version history was designed with the idea to replay every single revision that existed since the creation of the spreadsheet and apply it to the original data, and in case of missing revisions, in our example, B is missing, we detect the lack of continuity, we start from the snapshot, and replay every single revision since that snapshot. When the migration fixes the continuity, by deleting all the old revisions, and changing their order, we can no longer detect the lack of continuity and end up replay every available revision to the original data ,even though they are based on the snapshot. In that scenario, since the revisions will be applied on the original data but since they are based on the state of the snapshot only, the final state of the spreadsheet will be corrupted since a part of the . If a user then decides to restore the spreadsheet to the version they see in the version history (which is corrupted as mentioned) and the last snapshot is overwritten with the corrupted state, effectively breaking the spreadsheet. With this revision, we add a detection of this corrupted history state, in which case we enforce the history to be replayed from the snapshot and not the original data. Task-6533708
Documentation and clarification updates
This update records that Victor Hachard has signed Odoo's Contributor License Agreement. It helps ensure future contributions can be accepted under Odoo's legal contribution process.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Signing against 17.0 so the signature is forward-ported to all newer versions, as advised in #139403.