Odoo Changelog — 2026-04-10

Friday, April 10, 2026

11 changes · 17.0

Bug Fixes(11)

Resolved issues and error corrections

[FIX] l10n_lu_reports: Show all products without internal refs

Enterprise17.0l10n_lu_reports

This update resolves an issue where the LU reports were incorrectly showing only the first product with a missing internal reference. The change ensures all products with missing internal references are now displayed, providing a more accurate and complete report for Luxembourg accounting. This aligns with reporting requirements and improves data accuracy.

Original PR description

This is one of several commits fixing the FAIA xml export.

The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products.

opw-5427296, opw-6113665

#reporting#accounting#LU#FAIA

[FIX] l10n_ch_hr_payroll: Neutralize transmission in non prod-env

PR #113504

Enterprise17.0l10n_ch_hr_payroll

This update corrects a technical issue that could inadvertently transmit payroll data in non-production (test) environments. This change ensures that sensitive payroll information remains isolated to testing, improving data security and preventing potential errors. It’s a routine maintenance fix to maintain the integrity of our payroll system.

#payroll#ch#testing#security

[FIX] l10n_lu_reports: Prevent negative debit and credit amounts

PR #113316

Enterprise17.0l10n_lu_reports

This update corrects a bug in the l10n_lu_reports module that caused incorrect calculations of debit and credit amounts in reports. Specifically, it addresses a situation where negative price units resulted in invalid report totals. This ensures accurate financial reporting and avoids validation errors.

Original PR description

This is one of several commits fixing the FAIA xml export:
- #113452
- #113455
- #113846
- #113720

When an invoice line has a negative `price_unit`,  the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some
credit amounts and vice versa.

Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount
element.

opw-5427296
[Link](https://www.odoo.com/odoo/unassigned-tasks/5427296)

#reporting#accounting#lu

[FIX] hr_payroll: fix payslip warning bug

PR #112758

Enterprise17.0hr_payroll

This update fixes a misleading warning that appeared when generating payslips, specifically related to contract dates overlapping with payslip periods. The change improves the user experience by removing the warning when a contract partially overlaps with a payslip, aligning with the behavior in version 19. This ensures accurate payslip generation without unnecessary alerts.

Original PR description

Bug reproduction:
    1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
    2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
    3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
    4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.

Bug cause:
    1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
    2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear

Bug solution:
    1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"

Tests:
    1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
    2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)

Last Test Update:
    1 - I noticed that contract date changes was not affecting the warning appearance directly
    2 - Unit test is expanded with contract date change and observing the warning appearance

Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.

task - 6006693

#payroll#payslip#warning#contract

[FIX] point_of_sale: allow simultaneous order to be saved

PR #253840

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

#it_edi#fatturapa#invoice#validation

[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

#mobile#chat#composer#UI

[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>

#spreadsheet#performance#stability

[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

[FIX] google_calendar: avoid cache invalidation

PR #152474

Core17.0google_calendar

This update optimizes the Google Calendar integration by preventing unnecessary cache invalidations when events are updated. The changes streamline the system's data writing process, improving performance and reducing potential delays. This results in a smoother user experience.

Original PR description

When a google event is updated, the cache is invalidated. This is not necessary as the event google_id didn't change.

Also, slightly simplify the ormcache since there is a single call with active_test=False

#google calendar#performance#cache

This is one of several commits fixing the FAIA xml export. The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products. opw-5427296, opw-6113665

This is one of several commits fixing the FAIA xml export: - #113452 - #113455 - #113846 - #113720 When an invoice line has a negative `price_unit`, the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some credit amounts and vice versa. Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount element. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296)

Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format. 3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups. 4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue. Bug cause: 1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing. 2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear Bug solution: 1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period" Tests: 1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts. 2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period) Last Test Update: 1 - I noticed that contract date changes was not affecting the warning appearance directly 2 - Unit test is expanded with contract date change and observing the warning appearance Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well. task - 6006693

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

When a google event is updated, the cache is invalidated. This is not necessary as the event google_id didn't change. Also, slightly simplify the ormcache since there is a single call with active_test=False