Monday, June 1, 2026
5 changes · 17.0
Resolved issues and error corrections
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.
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
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
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
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