Odoo Changelog — 2026-06-01

Monday, June 1, 2026

7 changes · 17.0

Bug Fixes(7)

Resolved issues and error corrections

[FIX] account_intrastat: raise error only when saving intrastat code on product templates with dynamic attributes and no variants

Enterprise17.0account

This update resolves an issue where an error was incorrectly triggered when setting intrastat codes on product templates. The fix ensures the error only appears when a product template lacks variants and uses dynamic attributes, preventing unnecessary disruptions during product creation. This improves the stability and usability of the product template feature.

Original PR description

Problem:
When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template.

Solution:
The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error.

#intrastat#product#template#error

[FIX] sale: respect user-defined default email template

PR #265766

Core17.0sale

This update ensures that sales orders can now send emails using the user-selected email template, rather than the standard one. Previously, the system ignored custom default templates. This change improves flexibility and allows for branded email communications.

Original PR description

Steps to reproduce:
---
- Install the `Sales` module.
- Create a sale order and click Send by Email.
- Select an email template other than the default one.
- Open the Developer Tools (debug icon) > Set Default values.
- Set the selected template as the default and save.
- Try to send an email for a sale order again.

Issue:
---
- The newly saved default email template is ignored, and the system continues to load the standard template.

Root cause:
---
- The `Send by Email` action does not check for custom default templates set before loading the composer.

Solution:
---
- Modify the logic in the sales module to check for and respect saved default templates for the sale order model.

opw-6187942

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

#email#sales#template

[FIX] test_http: handle PicklingError in Python 3.14 session tests

PR #266862

Core17.0test_http

This update resolves an issue where Odoo's session tests were failing in Python 3.14 due to a change in how Python handles function pickling. The fix ensures the tests accurately detect the correct error type, maintaining the stability of the session serialization process.

Original PR description

Python 3.14 now raises `pickle.PicklingError` instead of `AttributeError` when attempting to pickle local functions or lambdas. This updates the session serialization assertions to expect the correct exception depending on the current Python version.

runbot-938172

#testing#compatibility#python

[FIX] account: prevent traceback with empty attachment

PR #267188

Core17.0account

This update corrects a technical issue within the Odoo accounting module that could cause errors when handling attachments without content. The fix ensures the system doesn't generate tracebacks, improving stability and preventing potential disruptions to users. This change focuses on internal technical improvements.

Original PR description

In https://github.com/odoo/odoo/commit/b86104514acf631003812ba8d120cc7b69d7da95
guess_mimetype is given a string fallback in case of no
attachment content. However the fallback type is wrong and may lead to a
traceback.

no-opw

#account#attachments#stability

[FIX] l10n_es_edi_sii: reflect quarterly tax periodicity in invoice JSON

PR #264063

Core17.0l10n_es_edi_siiMEDIUM

This update fixes an issue where SII invoice JSON files weren't correctly displaying quarterly tax periods. The change ensures that the generated JSON accurately reflects the company's chosen quarterly periodicity, aligning with Spanish tax regulations. This improves data accuracy for tax reporting.

Original PR description

### Issue:
When the company `tax_periodicity` is set to quarterly, the generated SII invoice JSON still uses the monthly period format

According to the documentation, the options for Periodo include distinction between monthly and trimester (p224 - 225):
https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII-Descripcion-ServicioWeb-v1-1_es_es.pdf

### Cause:
The invoice JSON generation does not consider the company's `tax_periodicity`

This logic was probably omitted because `account_reports` may not be installed
However, when the periodicity is configured, the generated SII document should reflect it correctly

### Steps to reproduce:
- Install `l10n_es_edi_sii` and `account_reports`
- In Settings, set `Tax Periodicity` to `Quarterly`
- In Settings, set `Tax Agency for SII` to `Agencia Tributaria Española`
- Change ES Company vat number to `ESA12345674`
- Create an invoice (Date: 01/05/2026, Customer: ES Company)
- Open the generated JSON document
- Check the Periodo value, it should be 2T in May

opw-6050587

#es_edi#sii#tax#reporting

[FIX] account: ensure correct sorting by status on portal page

PR #262976

Core17.0accountMEDIUM

This update corrects a bug where invoices on the customer portal were not sorted correctly by payment status. The fix changes the sorting field to reflect the actual payment state (e.g., 'In Payment') instead of the invoice's internal status. This ensures customers see invoices in the correct order based on their payment progress.

Original PR description

Steps to produce:
---
- Install the `Accounting` module.
- Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid).
- Log in as the portal user.
- Navigate to the invoices list and attempt to sort by **Status**.

Issue:-
---
- Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering.

Root cause:
---
- At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state.

Fix:
---
- Update the sorting configuration to use payment_state instead of state,
  ensuring that invoices are sorted correctly according to their payment
  status on the portal.

[1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52

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

#portal#invoices#payments

[FIX] calendar: preserve duration when opening full form from quick create

PR #257294

Core17.0calendar

This update fixes an issue where the duration of calendar events created via drag-and-drop wasn't accurately displayed in the full event form. Users could now correctly see the event's duration based on their adjusted end time after creating it. This ensures a more accurate and intuitive event management experience.

Original PR description

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the…

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop.

calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context.

https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19

duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field.

Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration.

Steps to reproduce:
1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00)
2. In the quick-create popover, change the end time to 14:00
3. Click "More Options"
4. Check the Duration field in the full form

=> Duration shows the original drag value (02:00) instead of 04:00

opw-6087449

#calendar#event#duration

Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error.

Steps to reproduce: --- - Install the `Sales` module. - Create a sale order and click Send by Email. - Select an email template other than the default one. - Open the Developer Tools (debug icon) > Set Default values. - Set the selected template as the default and save. - Try to send an email for a sale order again. Issue: --- - The newly saved default email template is ignored, and the system continues to load the standard template. Root cause: --- - The `Send by Email` action does not check for custom default templates set before loading the composer. Solution: --- - Modify the logic in the sales module to check for and respect saved default templates for the sale order model. opw-6187942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Python 3.14 now raises `pickle.PicklingError` instead of `AttributeError` when attempting to pickle local functions or lambdas. This updates the session serialization assertions to expect the correct exception depending on the current Python version. runbot-938172

In https://github.com/odoo/odoo/commit/b86104514acf631003812ba8d120cc7b69d7da95 guess_mimetype is given a string fallback in case of no attachment content. However the fallback type is wrong and may lead to a traceback. no-opw

### Issue: When the company `tax_periodicity` is set to quarterly, the generated SII invoice JSON still uses the monthly period format According to the documentation, the options for Periodo include distinction between monthly and trimester (p224 - 225): https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII-Descripcion-ServicioWeb-v1-1_es_es.pdf ### Cause: The invoice JSON generation does not consider the company's `tax_periodicity` This logic was probably omitted because `account_reports` may not be installed However, when the periodicity is configured, the generated SII document should reflect it correctly ### Steps to reproduce: - Install `l10n_es_edi_sii` and `account_reports` - In Settings, set `Tax Periodicity` to `Quarterly` - In Settings, set `Tax Agency for SII` to `Agencia Tributaria Española` - Change ES Company vat number to `ESA12345674` - Create an invoice (Date: 01/05/2026, Customer: ES Company) - Open the generated JSON document - Check the Periodo value, it should be 2T in May opw-6050587

Steps to produce: --- - Install the `Accounting` module. - Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid). - Log in as the portal user. - Navigate to the invoices list and attempt to sort by **Status**. Issue:- --- - Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering. Root cause: --- - At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state. Fix: --- - Update the sorting configuration to use payment_state instead of state, ensuring that invoices are sorted correctly according to their payment status on the portal. [1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52 opw-6128998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop. calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context. https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19 duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field. Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration. Steps to reproduce: 1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00) 2. In the quick-create popover, change the end time to 14:00 3. Click "More Options" 4. Check the Duration field in the full form => Duration shows the original drag value (02:00) instead of 04:00 opw-6087449