Thursday, July 17, 2025
6 changes · 17.0
Resolved issues and error corrections
The checkout extra step no longer records the Turnstile captcha response in sales order notes. This keeps customer order records cleaner and avoids storing long, irrelevant verification data.
Original PR description
Scenario:
- enable extra step in website ecommerce
- enable turnstile
- do the checkout process until after "extra step" step
- go check the sale order
Result: there is a big "turnstile_captcha: {1000 character hash}" that is
logged each time the customer filled the "extra step" step.
Cause:
turnstile if enabled is activated for all website_form and will add a
turnstile_captcha parameter.
For other website.form, the captcha is removed from the params when
calling:
request.env['ir.http']._verify_request_recaptcha_token('website_form')
but the custom route /website/form/shop.sale.order doesn't do that so
the captcha is logged in note.
Fix:
Recaptcha is already disabled on the extra_step with the class:
s_website_form_no_recaptcha, so it makes sense to just have the
same behavior for turnstile.
opw-4934132This fixes a wording mismatch in website sales emails by ensuring the word “order” uses the same lowercase style as the email text. The change helps avoid automated test failures and keeps customer-facing email wording consistent.
Original PR description
in the email body it is 'order' not 'Order' , check the error in the runbot build error log build_error-223173 Forward-Port-Of: odoo/odoo#219388
Electronic invoice exports now include the product barcode in the same standard field already used when importing invoices. This improves consistency between imports and exports and helps trading partners identify products more reliably.
Original PR description
[FIX] account_edi_ubl_cii: export product barcode too Currently we use the `Item/StandardItemIdentification` as the barcode when importing a product. But we do not export the same information. In 18.0+ the `Item/StandardItemIdentification` was added to the UBL XML (for exporting) in commit 72e312815f372de88388c47c612bb5f44b4d8b4e. But there it is only used in `l10n_co_dian`. After this commit we export and fill the tag "by default". task-4941855
Behavior before commit: In the Luxembourg tax report, certain SME-related field (481) was missing from the electronic declaration when the user language was set to French. This caused a crash (KeyError: '481') during report export, as the system failed to locate the required lines. Root cause: The report logic parsed the line code by splitting the translated name field of the report line (e.g., 481 - SME Revenue Threshold). However, the French translation did not preserve the numeric co
Original PR description
Behavior before commit: In the Luxembourg tax report, certain SME-related field (481) was missing from the electronic declaration when the user language was set to French. This caused a crash…
Behavior before commit:
In the Luxembourg tax report, certain SME-related field (481) was missing from the electronic declaration when the user language was set to French. This caused a crash (KeyError: '481') during report export, as the system failed to locate the required lines.
Root cause:
The report logic parsed the line code by splitting the translated name field of the report line (e.g., 481 - SME Revenue Threshold). However, the French translation did not preserve the numeric code prefix (481 - ...) — it was simply 'Seuil de revenus PME'. As a result, the code failed to detect the line, skipping it entirely.
Fix:
Updated the fr.po translation file to ensure the translated name for the SME report lines starts with the corresponding numeric code ('481 -' ). This allows the report logic to correctly identify and process these lines in all languages.
Steps to reproduce:
1. Set your user language to French.
2. Go to Accounting > Reporting > Luxembourg VAT Report.
3. Generate a report for any period.
4. Try to export the report in XML format.
5. Observe a crash (KeyError: '481') due to missing SME fields.
opw-4860455
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216517This fixes a configuration issue in the Swiss payroll ELM transmission module by removing an inappropriate preset value from a linked setting. The change helps ensure payroll transmission settings reflect the actual company configuration instead of an unintended default.
Original PR description
…lated field
This fix ensures the Belgian POS blackbox reliably loads the products used to record staff work-in and work-out actions. It prevents missing product data from causing errors during point-of-sale sessions.
Original PR description
Before this commit, there was an issue where work-in and work-out products could be missed during the loading process, leading to errors. opw-3999947 Forward-Port-Of: odoo/enterprise#65175