Thursday, September 11, 2025
11 changes · 17.0
Resolved issues and error corrections
Mollie payments that remain open, such as SEPA bank transfers, are now treated as pending instead of causing an error after checkout. This prevents customers and merchants from seeing an incorrect payment status warning while the payment is still waiting to complete.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Mollie as a payment provider; 2. set up an eCommerce order in EUR; 3. go to checkout; 4. pay via Mollie; 5. pick SEPA bank transfer as payment method; 6. leave the transaction open. Issue ----- When returning from the redirect, we get the following error message: > Mollie: Received data with invalid payment status: open Cause ----- An 'open' payment indicates the payment has been created, but nothing else has happened yet[^1]. This is the expected status for bank transfers, but is currently not getting handled in `_process_notification_data`, leading to the error. [^1]: https://docs.mollie.com/docs/status-change Solution -------- Handle 'open' payments the same as 'pending' ones. opw-4894556 Forward-Port-Of: odoo/odoo#225875
Sales orders created from a contact now use that customer's preferred delivery address instead of defaulting to the first saved address. This makes address selection consistent between the Contacts and Sales apps, reducing shipping mistakes and manual corrections.
Original PR description
## Versions 17.0+ ## Issue When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery…
## Versions
17.0+
## Issue
When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery address. This fix ensures consistent behavior across both.
## Steps to reproduce
*Ensure Contacts app is installed*
*Activate "Customer Addresses" in the settings*
- Go to the Contacts app:
- Create a new contact:
- Name: C1;
- Contacts & Addresses:
- Delivery Address (Add 2 new addresses):
- D1;
- D2.
- Click the "Sales" action button:
- Create a new SO for C1 (pre-filled):
- Invoice Address: C1, D2;
- Delivery Address: C1, D2;
- Add any product with:
- Quantity: 1;
- Delivered: 1.
- Create the invoice and confirm it.
- Go back to Contacts and look for C1:
- Click the the "Sales" action button:
- Create a new SO and see the Delivery Address set to "C1, D1".
- Go to Sales app:
- Create a new SO and select C1 as customer;
- Delivery Address retrieves "C1, D2" as it is the preferred address.
## Cause
Each time an invoice is validated, the corresponding address gets a higher score.
This score is then used in the SQL ordering of customers/suppliers:
https://github.com/odoo/odoo/blob/b523f5c6d8e235a6cedb029f701a0ebd89a5f74a/addons/account/models/partner.py#L347-L354
## Fix
Apply context search mode if first call. This mimics the base behavior: https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/odoo/addons/base/views/res_partner_views.xml#L534
opw-4916381Stripe card payment fields now use the language selected on the website instead of defaulting to the shopper's browser language. This keeps checkout wording consistent for multilingual websites and reduces confusion during payment.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable Stripe; 2. enable a second language on the website; 3. use second language on website; 3. go to checkout; 4. open card payment method. Issue ----- The card field values are displayed using the current browser's locale instead of the website's language. Cause ----- The `locale` parameter isn't included when connecting to the Stripe API. Solution -------- Include the lang from the `html` element via `_prepareStripeOptions`. If not present, let it fall back on the browser's locale. opw-5024805
This update brings the spreadsheet component to its latest version and fixes issues affecting Excel imports and array formulas. Users should see fewer unnecessary warnings when importing files and more reliable spreadsheet behavior when formulas are imported or cells are inserted.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a11c622ad [REL] 17.0.73 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a11c622ad [REL] 17.0.73 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5043de9f2 [FIX] xlsx: remove useless warnings on import [Task: 5075112](https://www.odoo.com/odoo/2328/tasks/5075112) https://github.com/odoo/o-spreadsheet/commit/4f1f8306d [FIX] xlsx: `=undefined` when importing array formula [Task: 4812508](https://www.odoo.com/odoo/2328/tasks/4812508) https://github.com/odoo/o-spreadsheet/commit/53296c842 [FIX] clipboard: insert cells bugged with array formulas [Task: 4938311](https://www.odoo.com/odoo/2328/tasks/4938311) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Financial account roots are now kept separate per company, preventing duplicate records from being mixed together in multi-company setups. This avoids access errors when users filter analytic reports by financial account root and makes reporting navigation more reliable.
Original PR description
account.root is an SQL view built from account_account.code. Its ids were computed from ASCII(code) (and the second character) without including company_id. In multi-company databases this generated…
account.root is an SQL view built from account_account.code. Its ids were computed from ASCII(code) (and the second character) without including company_id. In multi-company databases this generated the same id for the same root (e.g., "6", "60") across companies, which breaks the ORM’s uniqueness assumption for ids. Duplicates in search/read (same id repeated as many times as there are companies). AccessError at web_search_read/read with allowed_company_ids set, because when we want to serch/read them we look for something like `id in [1, 2, ...]` but we put the same id for the same root in each company so when we get id 1, we will get id for each company (if we have 3 companies we will get 3 id(1) but only one of them belongs to the active company) and when chicking if they are in the allowed company we hit the access error because (in case of only one company is active) we have access only to the root of the active company. Steps to reproduce: On runbot go to Analytic reporting Add Custom Filter: `Financial Account` > `Root` when you want to set when `Financial Account` is in, click load more. you'll hit the access error Fix Prefix both id and parent_id with company_id (company_id * 100000 + ASCII(...)). This yields one row per (company, prefix), keeping global uniqueness. Also update the `account.account.root_id` compute to use the same company-scoped formula and add `company_id` to `@api.depends` so it recomputes when the company changes. opw-4703049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Neutralized databases now prevent existing Peppol connections from contacting live or test networks by switching them to a local demo mode. New Peppol connections from these databases will use the test network, reducing failed registrations and avoiding accidental production use.
Original PR description
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network,…
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network, therefore the database is in an inconsistent state, and calls to the test network are very likely to fail - if you create a new connection to Peppol on a neutralized database, since the system parameter was not changed, the new connection was on production After this commit: - existing connections are switched in `demo` where everything is mocked locally, no call to the network (whether it's `test` or `prod` can happen) - the system parameter is switched to `test`, therefore new connections will register to the Peppol test network - Also added some fields on the Edi Proxy User to display the mode of the user, as well as the proxy_type in list view. (Those records are only accessible in debug already.) <img width="579" height="333" alt="image" src="https://github.com/user-attachments/assets/87847726-d954-4f68-8336-07771747365f" /> task-none (report from PMAX + WTA)
This fix ensures Razorpay OAuth webhook links are built correctly when website payments are enabled. It prevents failed authentication caused by malformed URLs, helping businesses complete payment provider setup without interruption.
Original PR description
A bad URL could be generated when the `website_payment` module is installed, as it overrides `get_base_url` and may return a URL ending with `/`. Using f-strings to create URLs could result in a double slash `//`, causing errors. Steps to reproduce: - Install `website_payment` and `payment_razorpay_oauth` - Go to Payment Acquirers and connect via OAuth - Click "Generate your webhook" - "Authentication failed" error appears This fix uses `url_join`, like other payment providers, to build URLs correctly and avoid the double slash issue. opw-5079295
Corrects a rounding mismatch that could cause Mexican electronic payment documents to be rejected when a foreign-currency invoice is paid in Mexican pesos. This helps businesses successfully validate and send payment CFDIs in cases involving exchange-rate precision differences.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981Approvers who are specifically asked to approve a request can now complete their approval even if they do not have the broader Approvals user role. This prevents valid approvals from being blocked by unnecessary access restrictions and helps approval workflows move forward as expected.
Original PR description
Follow up on the previous PR odoo/enterprise#92309 , fixing access rights preventing approvers from approving in requests they are requested to approve in case they don't have the group approvals user. Task-4897775
This fix reports point-of-sale service items with a quantity of zero in India GSTR returns, matching GST portal requirements. Goods continue to show their actual sold quantity, helping businesses avoid validation errors when filing returns.
Original PR description
Before this PR: - Service products in POS GSTR lines were reported with their actual quantity. - This caused GST portal validation error: `RET191355: The Quantity entered is not valid`. After this PR: - For service-type products, `qty` is always set to `0`. - For goods, `qty` continues to reflect the actual ordered quantity. OPW: 5070636
This fix prevents an error when posting Italian tax return closing entries. It ensures the system correctly evaluates the related accounting search, allowing Italian companies to complete the tax return workflow reliably.
Original PR description
The `osv.expression.AND` operator was incorrectly used, leading to an invalid search domain and raising an error. Steps to reproduce: - Set the company country to Italy - Go to Accounting > Reporting > Tax return - Create a closing entry - Try to post the closing entry - An error is raised: ```python elif token[1] == 'in' and not (isinstance(token[2], Query) or token[2]): ~~~~~^^^ IndexError: string index out of range ``` The fix wraps the subdomain in a list so the domain is properly evaluated. opw-5075640