Odoo Changelog — 2026-04-10

Friday, April 10, 2026

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] point_of_sale: allow simultaneous order to be saved

Core17.0point_of_saleMedium

This update resolves an issue where simultaneous POS operations (across multiple devices) caused order synchronization problems. Previously, changes made in one POS wouldn't consistently reflect in other POS instances. The fix ensures that orders are correctly updated across all connected POS devices, improving data accuracy and operational efficiency.

Original PR description

Step to reproduce:
- have two pos, both trust each other, pos  A and B
- open pos A , create a order and save it
- go to backend , open pos B
- process the order, go to backend
- open pos A (notice, last save order is still loaded)
- removed older lines, and add new ones and save this again
- go to backend and open pos B
- notice that order is not loaded in other pos

Cause:
- Draft orders are stored in local storage.
- When shared with another POS, `pos.order` is created via `create_from_ui` and receives a `server_id`.
- If that order is later processed from another POS, the backend state changes.
- When the original POS is reopened, the local data still treats the order as draft.
- Saving the order again does not create a new order because it already has a `server_id`.
- This causes inconsistency with the backend and prevents the order from appearing in other POS sessions.

Fix:
- Before loading orders from JSON, verify that orders with `server_id` are still in `draft` state on the server.
- Discard orders whose backend state is no longer `draft`. 
 
opw-5946355

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#pos#order#synchronization

[FIX] l10n_it_edi: normalize UoM's non-standard Unicode chars in XML

PR #257012

Core17.0l10n_it_ediMedium

This update resolves a problem where electronic invoices (FatturaPA) generated with units of measure containing special characters failed validation. The fix normalizes these characters to ensure the XML complies with the required format, allowing invoices to be correctly processed by tax authorities. This prevents invoice rejection and ensures compliance.

Original PR description

### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails…

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] mail: prevent composer focus loss with active mobile menus

PR #250294

Core17.0mailMedium

This update resolves a bug where the chat composer on mobile devices would become unresponsive when the navigation menu was open. The fix prevents the navigation menu from stealing focus from the composer, ensuring users can consistently type messages. This improves the mobile chat experience.

Original PR description

**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.…

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus.

Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #258574

Core17.0spreadsheetMedium

This update fixes several issues within the Odoo spreadsheet library, improving its stability and rendering performance. It includes bug fixes related to conditional formatting and browser compatibility, ensuring a smoother user experience. This change was made by a team of developers to maintain the quality of the spreadsheet functionality.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3b0f1d2600 [REL] 17.0.89 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/3b0f1d2600 [REL] 17.0.89 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7abf8f9dd0 [REM] doc: remove tsdoc [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/208f0e8511 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/c3eca65cdc [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/a1d9f1bb45 [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/148bd3c9d8 [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/6a0f89d792 [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
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: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

[FIX] point_of_sale: remove stale orders from localStorage on load

PR #252846

Core17.0point_of_saleMedium

This update corrects a bug where paid orders from one Point of Sale configuration (S1) would incorrectly appear as unpaid in another (S2) after reopening S1. The fix ensures that outdated order data is removed from local storage, preventing these inconsistencies and improving the overall PoS experience.

Original PR description

Steps to reproduce:
-------------------
1. Create 2 mutually trusted PoS configs (S1 and S2).
2. From S1, create an order, save it, and close the PoS.
3. Open S2, go to ticket screen, and pay S1's order.
4. Reopen S1.

-> The paid order still appears as unpaid in S1.

The fix:
--------
In `load_server_orders`, after loading open orders, remove the local
orders from LS that are still considered "draft', but are now paid by
other shops. If during that process, the selected order was removed, we reset it
and call `set_start_order` which adds a new one.

Note: this fix is similar to what's done when going to the ticket screen
where the function `_syncAllOrdersFromServer` is being called: all the
local orders that are not anymore draft are removed from local storage's
open orders.

opw-5946365

#pos#order#localStorage

[FIX] account_edi_ubl_cii: Changing tax exemption reason when no tax

PR #256663

Core17.0account_edi_ubl_ciiMedium

This update corrects an issue where early payment discounts and 0% tax lines on invoices were causing validation errors when sending invoices via PEPPOL. The fix ensures the correct tax exemption reason is used, resolving XML validation problems and enabling proper invoice export.

Original PR description

**PROBLEM**
Early payment discount create a new line which is tax exempted. The tax exemption reason is 'Exempted from tax'.
0% tax also have a tax exemption reason that is different, which means the tax exemption subtotal are not merged.

**STEP TO REPRODUCE**
1. Create a early payment discount payment term.
2. Create an invoice, with a line with a 0% tax and the early payment term.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

A similar issue was fix in 18.0 by https://github.com/odoo/odoo/pull/250413, and the fix works for this bug.

opw-6075910

#ubl#peppol#tax#invoice

Step to reproduce: - have two pos, both trust each other, pos A and B - open pos A , create a order and save it - go to backend , open pos B - process the order, go to backend - open pos A (notice, last save order is still loaded) - removed older lines, and add new ones and save this again - go to backend and open pos B - notice that order is not loaded in other pos Cause: - Draft orders are stored in local storage. - When shared with another POS, `pos.order` is created via `create_from_ui` and receives a `server_id`. - If that order is later processed from another POS, the backend state changes. - When the original POS is reopened, the local data still treats the order as draft. - Saving the order again does not create a new order because it already has a `server_id`. - This causes inconsistency with the backend and prevents the order from appearing in other POS sessions. Fix: - Before loading orders from JSON, verify that orders with `server_id` are still in `draft` state on the server. - Discard orders whose backend state is no longer `draft`. opw-5946355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format. ### Steps to reproduce the issue: 1. Download Italian loc + electronic invoicing 2. Activate UoM option in settings 3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3) 4. Invoice this product 5. Create the XML for SdI 6. Check format with Fex > apex is not recognised as a valid character ### Cause of the issue: The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications. ### Reason to introduce the fix: Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules. opw-6075119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open. https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef Steps to reproduce: 1. Open the website in a mobile view. 2. Tap the navbar toggler to open the mobile menu. 3. Without closing the menu, open the chat window. 4. Tap on the message composer text area. → The composer is not accessible. This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard. This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus. Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3b0f1d2600 [REL] 17.0.89 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7abf8f9dd0 [REM] doc: remove tsdoc [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/208f0e8511 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/c3eca65cdc [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/a1d9f1bb45 [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/148bd3c9d8 [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092) https://github.com/odoo/o-spreadsheet/commit/6a0f89d792 [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Steps to reproduce: ------------------- 1. Create 2 mutually trusted PoS configs (S1 and S2). 2. From S1, create an order, save it, and close the PoS. 3. Open S2, go to ticket screen, and pay S1's order. 4. Reopen S1. -> The paid order still appears as unpaid in S1. The fix: -------- In `load_server_orders`, after loading open orders, remove the local orders from LS that are still considered "draft', but are now paid by other shops. If during that process, the selected order was removed, we reset it and call `set_start_order` which adds a new one. Note: this fix is similar to what's done when going to the ticket screen where the function `_syncAllOrdersFromServer` is being called: all the local orders that are not anymore draft are removed from local storage's open orders. opw-5946365

**PROBLEM** Early payment discount create a new line which is tax exempted. The tax exemption reason is 'Exempted from tax'. 0% tax also have a tax exemption reason that is different, which means the tax exemption subtotal are not merged. **STEP TO REPRODUCE** 1. Create a early payment discount payment term. 2. Create an invoice, with a line with a 0% tax and the early payment term. 3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08]. A similar issue was fix in 18.0 by https://github.com/odoo/odoo/pull/250413, and the fix works for this bug. opw-6075910