Odoo Changelog — 2026-04-02

Thursday, April 2, 2026

8 changes · 17.0

Bug Fixes(8)

Resolved issues and error corrections

[Fix] mail: backport QWeb rendering error clarity

Core17.0mailMEDIUM

This update reduces log clutter when QWeb templates fail to render, making it easier for support teams to diagnose issues. The change intelligently truncates template logs while retaining full source for unidentified errors, improving system performance and support efficiency.

Original PR description

This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate.

Summary:

When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error.

This commit improves the error handling in `mail.render.mixin` and `mail.template` by:

- mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing).
- Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates.

OPW-5980295


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

#QWeb#rendering#log management

[FIX] account_edi_ubl_cii: Allow only invoices can be grouped

PR #255359

Core17.0account_edi_ubl_cii

This update ensures that line grouping functionality within the account_edi_ubl_cii module is limited to invoices only. Previously, this feature could be applied to other document types like journal entries, which could cause errors. This change improves data integrity and prevents potential issues related to incorrect grouping.

Original PR description

[FIX] account_edi_ubl_cii: Allow only invoices can be grouped

Before this commit, no check was done on the document type at line grouping. This commit adds the check `is_invoice` so that we cannot group (e.g.) a journal entry type move

no-task

#account_edi#ubl#cii#invoice

[FIX] hr_holidays : Automatically calculate the allocation duration when different mode

PR #247091

Core17.0hr_holidaysMEDIUM

This update fixes an issue where accrual calculations weren't working correctly for allocation modes other than 'By Employee'. The change ensures that allocation durations are automatically calculated accurately, regardless of the chosen allocation mode, improving the reliability of holiday accruals. This resolves a previous bug impacting how employees accrue time off.

Original PR description

### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the…

### Steps to reproduce:
	- Create an accrual plan of one level to give 20 days at the start of the year
	- Create an allocation with different mode than 'By Employee'
	- Set the accrual plan for the allocation and date from 1st Jan
	- Notice the Allocation number of days doesn't get automatically calculated

### Cause:
This is happening because when trying to process the accrual plan we won't have any records in the field employee_id

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893

And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'.

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270

### Fix:
If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null

P.S. In the forward port we will have to introduce another fix for the multi allocation wizard

opw-5888023

#hr#accrual#holidays

[FIX] base: Add to checklist before file write

PR #257274

Core17.0base

This update resolves an issue where attachment creation would fail if a write error occurred, leading to orphaned files and potential disk space problems. By ensuring attachments are properly cleaned up after failed writes, this fix prevents errors and improves attachment management within Odoo. It addresses previous issues opw-6055037 and opw-5907025.

Original PR description

If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written.

Step to reproduce the issue:
1. Create an attachment with a large file (e.g., 100MB) and save
2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions)
3. The file will not be marked for garbage collection, and it will remain
4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file."

opw-6055037
opw-5907025

#attachments#file management#error handling

[FIX] account_peppol: correct self-billing in multi-company

PR #256792

Core17.0account_peppolMEDIUM

This update fixes an issue where self-billed invoices received from Peppol companies were incorrectly assigned to the wrong company within a multi-company Odoo database. The change ensures invoices are routed to the correct company based on the current database setup, improving invoice processing accuracy and reducing potential errors. This resolves a previous bug impacting financial reporting.

Original PR description

Currently, if a database has multiple companies registered on Peppol, receiving a self-billed invoice may assign it to the wrong company. The system was searching the journal using a domain that included all companies (in self), instead of filtering by the correct current company.

Steps to reproduce:
- Create a database with 2 companies, both on Peppol
- Receive a self-billed invoice from a random other company on Peppol
- The received invoice will potentially be assigned to the wrong company

opw-6045669

#accounting#peppol#invoice

[FIX] account_intrastat: copy intrastat fields on vendor bill autocomplete

PR #111278

Enterprise17.0account_intrastat

This update fixes an issue where Intrastat fields weren't automatically populated when using the vendor bill autocomplete feature. The change ensures that country and transport mode information from previously entered bills is correctly copied to new bills, streamlining reporting for Intrastat compliance. This improves data accuracy and reduces manual effort.

Original PR description

**Steps to reproduce:**
1. Install module `account_intrastat`.
2. Go to Accounting > Vendors > Bills.
3. Create and post a vendor bill:
   - Set a vendor
   - Add a reference
   - Add a product line
   - Set Intrastat fields (enable them in settings if needed)
4. Create a new vendor bill with the same vendor.
5. Use the autocomplete (select previous bill reference).

**Issue:**
Intrastat fields (country and transport mode) are not copied from the selected bill.

**Cause:**
The `invoice_vendor_bill_id` onchange does not propagate Intrastat fields.

**Solution:**
Extend `_onchange_invoice_vendor_bill` to copy:
- `intrastat_country_id`
- `intrastat_transport_mode_id`

opw-5936869

#intrastat#vendor bills#reporting

[FIX] l10n_co_edi: remove duplicate selection

PR #110287

Enterprise17.0l10n_co_edi

A bug causing OWL crashes during invoice creation in the Colombian module (l10n_co_edi) has been resolved. The issue stemmed from a duplicate selection value within a field, leading to a JavaScript error. This fix ensures stable invoice creation for Colombian businesses.

Original PR description

The `l10n_co_edi_operation_type` field on `account.move` had two entries with the same selection value `'23'`:

('23', 'Nota Crédito para facturación electrónica V1 (Decreto 2242)'), ('23', 'Inactivo: Nota Crédito para facturación electrónica V1 (Decreto 2242)'),

This caused an OWL crash when opening the invoice form:
    "Got duplicate key in t-foreach: 23"

__Steps to reproduce:__
1- Install the l10n_co_edi module
2- switch to colombian company
3- Activate the developer mode
4- Go to Credit Note > Create

__NOTE__: The javascript error is only visible on version 18.4 but the duplicate selection is present since 17.0.

opw-5969595

#accounting#colombia#invoice

[FIX] l10n_ch_hr_payroll_elm_transmission: fix 6010 zip code mapping

PR #104904

Enterprise17.0l10n_ch_hr_payroll_elm_transmission

This update corrects a mapping error that was causing incorrect canton and municipality data to be populated for employees in the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission). Specifically, the zip code 6010 was incorrectly linked, ensuring accurate Swiss tax and social security reporting.

Original PR description

**Steps to reproduce:**
1. Install `l10n_ch_hr_payroll_elm_transmission`
2. Switch to Swiss company
3. Create an employee and fill in the zip code 6010 under the address section

**Issue:**
- Residence Canton is filled with Nidwalden Instead of Lucerne 
- Residence Municipality is filled with 1507 instead of 1059

**Cause:**
- Mapping is wrong in file `hr_payroll_rule_parameters.xml`

**Solution:**
- Set `'6010': ('Kriens', 1507, 'NW')` to `'6010': ('Kriens', 1059, 'LU')`
- Source: https://www.swisstopo.admin.ch/en/official-directory-of-towns-and-cities#Download

opw-5474083

#payroll#switzerland#zip code#tax

This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate. Summary: When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error. This commit improves the error handling in `mail.render.mixin` and `mail.template` by: - mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing). - Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates. OPW-5980295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] account_edi_ubl_cii: Allow only invoices can be grouped Before this commit, no check was done on the document type at line grouping. This commit adds the check `is_invoice` so that we cannot group (e.g.) a journal entry type move no-task

### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the allocation and date from 1st Jan - Notice the Allocation number of days doesn't get automatically calculated ### Cause: This is happening because when trying to process the accrual plan we won't have any records in the field employee_id https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893 And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'. https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270 ### Fix: If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null P.S. In the forward port we will have to introduce another fix for the multi allocation wizard opw-5888023

If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025

Currently, if a database has multiple companies registered on Peppol, receiving a self-billed invoice may assign it to the wrong company. The system was searching the journal using a domain that included all companies (in self), instead of filtering by the correct current company. Steps to reproduce: - Create a database with 2 companies, both on Peppol - Receive a self-billed invoice from a random other company on Peppol - The received invoice will potentially be assigned to the wrong company opw-6045669

**Steps to reproduce:** 1. Install module `account_intrastat`. 2. Go to Accounting > Vendors > Bills. 3. Create and post a vendor bill: - Set a vendor - Add a reference - Add a product line - Set Intrastat fields (enable them in settings if needed) 4. Create a new vendor bill with the same vendor. 5. Use the autocomplete (select previous bill reference). **Issue:** Intrastat fields (country and transport mode) are not copied from the selected bill. **Cause:** The `invoice_vendor_bill_id` onchange does not propagate Intrastat fields. **Solution:** Extend `_onchange_invoice_vendor_bill` to copy: - `intrastat_country_id` - `intrastat_transport_mode_id` opw-5936869

The `l10n_co_edi_operation_type` field on `account.move` had two entries with the same selection value `'23'`: ('23', 'Nota Crédito para facturación electrónica V1 (Decreto 2242)'), ('23', 'Inactivo: Nota Crédito para facturación electrónica V1 (Decreto 2242)'), This caused an OWL crash when opening the invoice form: "Got duplicate key in t-foreach: 23" __Steps to reproduce:__ 1- Install the l10n_co_edi module 2- switch to colombian company 3- Activate the developer mode 4- Go to Credit Note > Create __NOTE__: The javascript error is only visible on version 18.4 but the duplicate selection is present since 17.0. opw-5969595

**Steps to reproduce:** 1. Install `l10n_ch_hr_payroll_elm_transmission` 2. Switch to Swiss company 3. Create an employee and fill in the zip code 6010 under the address section **Issue:** - Residence Canton is filled with Nidwalden Instead of Lucerne - Residence Municipality is filled with 1507 instead of 1059 **Cause:** - Mapping is wrong in file `hr_payroll_rule_parameters.xml` **Solution:** - Set `'6010': ('Kriens', 1507, 'NW')` to `'6010': ('Kriens', 1059, 'LU')` - Source: https://www.swisstopo.admin.ch/en/official-directory-of-towns-and-cities#Download opw-5474083