Friday, October 10, 2025
6 changes · 18.0
Enhancements to existing features
The Spanish localization now separates Canary Islands purchase taxes for goods and services, aligning tax mappings with their business purpose. It also adds DUA-related Canary Islands tax data, helping companies apply more accurate tax treatment in this region.
Original PR description
We have splitted purchase taxes in goods and services because there are different mappings according to the scope. It has a similar functionality with spanish mainland taxes @jco-odoo There are doubts with the fiscal position `fp_nacional_canary_ns` as it is applied automatically to spanish non canarian partners but it should be similar to non-EU partners IMO. However, I think that the opinion fo some canary people would be nice to clarify it @Christian-RB --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updating customer contact details linked to many helpdesk tickets is now more reliable. The change reduces memory usage during these updates, helping prevent failures for customers with large ticket histories.
Original PR description
Issue: When updating partner fields such as `email`, `name` and `phone` on the partner records, the ticket fields are recomputed. During the recomputation, the `description` field is loaded into…
Issue: When updating partner fields such as `email`, `name` and `phone` on the partner records, the ticket fields are recomputed. During the recomputation, the `description` field is loaded into memory and with many helpdesk tickets, this will cause a memory error. Purpose of this PR: To explicity fetch `partner_id` before computing partner fields on the helpdesk ticket. Example: With a partner record with 25,000 helpdesk tickets each with a description of varying text and images, we hit the memory limit when trying to update the partner phone. With these changes, peak memory usage reached 271.4 MB. Notes: Originally wanted to avoid changing the field definition however this would require adding `with_context(prefetch_fields=False)` to most of the compute methods on helpdesk ticket model.`with_context(prefetch_fields=False)` to most of the compute methods on helpdesk ticket model. Memgraph and Stats before changes <img width="1912" height="862" alt="memgraph_b4_changes" src="https://github.com/user-attachments/assets/f5e95a42-83c8-4250-bdf3-440740a9fb33" /> <img width="640" height="352" alt="stats_b4_changes" src="https://github.com/user-attachments/assets/a82ccd69-1359-4ba8-81a0-52aeace762db" /> opw-5069424
Paired IoT Boxes now always connect to the database communication channel instead of relying on separate open or closed connection states. This simplifies troubleshooting and creates a more predictable experience when using IoT hardware with Odoo.
Original PR description
In order to simplify debugging and UX, we removed the open/closed WebSocket logic for IoT Boxes. A paired IoT Box should always connect to the db IoT WebSocket channel.
The Peppol invoice status information is consolidated in the accounting invoice view, making it easier for users to understand document delivery progress. This improves day-to-day visibility for teams managing electronic invoicing without changing core accounting workflows.
Original PR description
Cherry-pick of https://github.com/odoo/odoo/commit/114e8bc6f34da309fa1aa2160ef3319da098c48c opw-5106956
Point of Sale employee managers can no longer open the backend unless their employee profile is linked to the currently signed-in user. This helps keep backend access aligned with the actual logged-in account while still allowing managers to close POS sessions.
Original PR description
Task: [5154178](https://www.odoo.com/odoo/project/1737/tasks/5154178) --- Previously, any employee with the role `manager` could go to the backend. Now, the only employees that can go back to the backend are those binded to the user connected. Managers can still close the session.
Account merging now gathers existing account codes in one database step instead of checking each company one by one. This reduces delays during merge operations, especially for databases with many companies.
Original PR description
The merge wizard needs to collect the account codes of the accounts we are merging in order to write them on the merged account as the final step of the merging process. At the moment, collecting the account codes is done in Python and loops over all the existing root companies, retrieving the code of the account for each company. On a recent l10n [runbot](https://runbot.odoo.com/runbot/build/90542336) (with 146 companies), this was causing the merging step to take ~4.5 seconds per account, most of this time being taken just by collecting the account codes. Instead, we collect the codes in a single SQL query. Flamegraphs: [before.json](https://github.com/user-attachments/files/22726956/before.json) [after.json](https://github.com/user-attachments/files/22726960/after.json) task-none