Odoo Changelog — 2025-03-18

Tuesday, March 18, 2025

3 changes · saas-18.1

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_es_website_sale: only require VAT/NIF on invoice address

PR #202040

Coresaas-18.1l10n_es_website_saleMedium

Spanish e-commerce checkouts no longer incorrectly require VAT/NIF details on delivery addresses. VAT/NIF is now required only for invoice addresses, preventing blocked purchases while keeping Spanish invoicing requirements intact.

Original PR description

**How to reproduce?** 1. Have `l10n_es` installed with `website_sale` and make sure the website with e-commerce belongs to the Spanish company. 2. Create a contact with a Spanish parent company…

**How to reproduce?**

1. Have `l10n_es` installed with `website_sale` and make sure the website with e-commerce belongs to the Spanish company.
2. Create a contact with a Spanish parent company having a VAT number.
3. Add a delivery address to this contact.
4. Create a portal user for this contact.
5. Log in with the portal user on the website, add a product to the cart and try to check out by filling out any remaining delivery address fields and trying to continue.

**Observed behavior**

An error is raised because it can't find some missing required fields.

**Intended behavior**

No error should be raised, because the delivery address should not require these fields.

The bug was introduced in [this commit].

This fix makes sure that
- the fields `vat` and `state` are only required on the invoicing address,
- the "display B2B fields" option is automatically enabled for Spanish companies since the `vat` field is required on the invoicing address.

[opw-4610111](https://www.odoo.com/odoo/project.task/4610111)

[this commit]: https://github.com/odoo/odoo/commit/c63dcc3156235203e9a91a13c44001ecb99a1ffa

#checkout#Spain#VAT#ecommerce

[FIX] auth_signup, web: signup with captcha w/o error message

PR #202127

Coresaas-18.1auth_signupwebMedium

Users signing up or resetting their password with reCAPTCHA enabled are no longer sent back to the form with a misleading invalid token error after the action succeeds. This prevents confusion during account creation and password recovery while keeping the captcha validation in place.

Original PR description

Scenario: activate recaptcha, do a signup (or reset password)

Result: the signup is done, but we see an error "The reCaptcha token is
invalid." and reload the /web/signup form.

Issue:

In a0651c364be58a98e209ee413c1a9c79c72d874d the captcha validation on
login was done inside the method. But when creating a new account, we
were bypassing the login captcha check (that was already done on the
/web/signup or /web/reset_password route).

Fix: bypass the login captcha check by using a context key.

Note: without the fix, the modified test would fail with:

  AssertionError: '/web/login?redirect=%2Fweb%2Flogin_successful%3Faccount_created%3DTrue'
  not found in 'http://127.0.0.1:41811/web/signup'

opw-4641916

#signup#password reset#recaptcha

[FIX] l10n_mx_edi_pos: fix refund crash when the order is invoiced

PR #80664

Enterprisesaas-18.1l10n_mx_edi_posMedium

Refunding an invoiced Point of Sale order for a Mexican company no longer causes the payment screen to fail. The refund now carries the required Mexican electronic invoicing values, helping staff process returns without interruption.

Original PR description

**Steps to reproduce** - Install PoS, and select a Mexican company - Create an order O1, and in the payment screen, select "Invoice" and confirm the dialog - Validate the order - Click on "Orders"…

**Steps to reproduce**
- Install PoS, and select a Mexican company
- Create an order O1, and in the payment screen, select "Invoice" and confirm the dialog
- Validate the order
- Click on "Orders" and set the filter to "Paid" to see order O1
- Click O1, click "Refund", and from the product screen, click "Payment"

Observed behavior: White screen with traceback in the console.

**Issue**
It's happening because in l10n_mx_edi_pos, an invoiced order is supposed to have fields `l10n_mx_edi_cfdi_to_public` and `l10n_mx_edi_usage` https://github.com/odoo/enterprise/blob/a0a97f2c87f76ae035394a67b09d71ec8f4567e7/l10n_mx_edi_pos/static/src/app/screens/payment_screen/payment_screen.js#L18-L21 And they are being accessed in the `product_screen.xml` https://github.com/odoo/enterprise/blob/0396d4f0ac33640dc042bb97e9e8d4b498e6a128/l10n_mx_edi_pos/static/src/app/screens/payment_screen/payment_screen.xml#L7-L12 
That works for the original ordre (aka O1), however, when the refund order is created, we set its `to_invoice` to `true` if the original order is invoiced ([code](https://github.com/odoo/odoo/blob/53e7c0adf093dc950a42989a56b4594f734c17b2/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L69-L75)), but we don't set any values to the fields `l10n_mx_edi_cfdi_to_public` and `l10n_mx_edi_usage`, causing the crash in the payment screen.

**Fix**
If the refund order is invoiced, we set the `l10n_mx_edi_usage` to "G02" which corresponds to 'Returns, discounts or bonuses' (assuming that a refund can be seen as a 'return' here). We also copy the field `l10n_mx_edi_cfdi_to_public` from the original order.

opw-4608630

**How to reproduce?** 1. Have `l10n_es` installed with `website_sale` and make sure the website with e-commerce belongs to the Spanish company. 2. Create a contact with a Spanish parent company having a VAT number. 3. Add a delivery address to this contact. 4. Create a portal user for this contact. 5. Log in with the portal user on the website, add a product to the cart and try to check out by filling out any remaining delivery address fields and trying to continue. **Observed behavior** An error is raised because it can't find some missing required fields. **Intended behavior** No error should be raised, because the delivery address should not require these fields. The bug was introduced in [this commit]. This fix makes sure that - the fields `vat` and `state` are only required on the invoicing address, - the "display B2B fields" option is automatically enabled for Spanish companies since the `vat` field is required on the invoicing address. [opw-4610111](https://www.odoo.com/odoo/project.task/4610111) [this commit]: https://github.com/odoo/odoo/commit/c63dcc3156235203e9a91a13c44001ecb99a1ffa

Scenario: activate recaptcha, do a signup (or reset password) Result: the signup is done, but we see an error "The reCaptcha token is invalid." and reload the /web/signup form. Issue: In a0651c364be58a98e209ee413c1a9c79c72d874d the captcha validation on login was done inside the method. But when creating a new account, we were bypassing the login captcha check (that was already done on the /web/signup or /web/reset_password route). Fix: bypass the login captcha check by using a context key. Note: without the fix, the modified test would fail with: AssertionError: '/web/login?redirect=%2Fweb%2Flogin_successful%3Faccount_created%3DTrue' not found in 'http://127.0.0.1:41811/web/signup' opw-4641916

**Steps to reproduce** - Install PoS, and select a Mexican company - Create an order O1, and in the payment screen, select "Invoice" and confirm the dialog - Validate the order - Click on "Orders" and set the filter to "Paid" to see order O1 - Click O1, click "Refund", and from the product screen, click "Payment" Observed behavior: White screen with traceback in the console. **Issue** It's happening because in l10n_mx_edi_pos, an invoiced order is supposed to have fields `l10n_mx_edi_cfdi_to_public` and `l10n_mx_edi_usage` https://github.com/odoo/enterprise/blob/a0a97f2c87f76ae035394a67b09d71ec8f4567e7/l10n_mx_edi_pos/static/src/app/screens/payment_screen/payment_screen.js#L18-L21 And they are being accessed in the `product_screen.xml` https://github.com/odoo/enterprise/blob/0396d4f0ac33640dc042bb97e9e8d4b498e6a128/l10n_mx_edi_pos/static/src/app/screens/payment_screen/payment_screen.xml#L7-L12 That works for the original ordre (aka O1), however, when the refund order is created, we set its `to_invoice` to `true` if the original order is invoiced ([code](https://github.com/odoo/odoo/blob/53e7c0adf093dc950a42989a56b4594f734c17b2/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L69-L75)), but we don't set any values to the fields `l10n_mx_edi_cfdi_to_public` and `l10n_mx_edi_usage`, causing the crash in the payment screen. **Fix** If the refund order is invoiced, we set the `l10n_mx_edi_usage` to "G02" which corresponds to 'Returns, discounts or bonuses' (assuming that a refund can be seen as a 'return' here). We also copy the field `l10n_mx_edi_cfdi_to_public` from the original order. opw-4608630