Thursday, June 11, 2026
8 changes · master
Resolved issues and error corrections
This update fixes an issue where holiday periods incorrectly displayed as 12:00 AM to 12:00 AM in the calendar view. The fix ensures that the start and end times of holiday periods accurately reflect the selected time off, regardless of whether the day is a working or non-working day.
Original PR description
Steps to reproduce: - In Time Off, create a time off type considered as working time and make it selectable in Time Off - Create a time period of that type of time off from the calendar view on a non-working period - The displayed hours will be 12:00 AM to 12:00 AM instead of what was selected Reason: When calculating the requested hour from and to, the _set_request_hours function looked at the working schedule, and since the employee is not supposed to work at that time, it returned 12:00 AM for both the hour from and the hour to. How it was fixed: The _set_request_hours function now takes the selected requested hour from and hour to if the employee is not supposed to work on that day. Task ID: 6151502
This update adjusts the in-app guidance (tours) within the Account Reports module to reflect a recent change: message actions are now located in the 'More' menu. This ensures users can easily find and utilize these actions after the menu reorganization, improving usability.
Original PR description
Purpose of this commit: Since message actions, except Add a Reaction, have been moved into the More menu, this commit updates the tour selectors for the actions that were previously displayed inline and are now available inside the More menu. community: https://github.com/odoo/odoo/pull/268190 task-6275021
This update corrects a technical error that prevented the system from correctly retrieving default planning settings. The issue stemmed from how a recordset was being handled, leading to a system error. This fix ensures that planning settings are consistently and accurately retrieved, improving the reliability of the planning module.
Original PR description
`self` could be non-singletion recordset ``` (Pdb) p self.default_get(['repeat_interval']) *** ValueError: Expected singleton: planning.slot(227, 174) ``` See: 689a15b46c85774f3ab9ee4b9173a549c2ce1abf Forward-Port-Of: odoo/enterprise#120080
This update fixes an issue in the GSTR-1 report generation where document number ranges were incorrectly calculated. The change ensures accurate identification of invoice sequences by using the sequence number instead of the invoice name, preventing misleading results and improving report accuracy.
Original PR description
Steps to reproduce: 1. Install `l10n_in_reports` and set tax return periodicity. 2. Create multiple invoices in same month and name them like "INV/2026/8" to "INV/2026/12" (5 invoices) 3. Create…
Steps to reproduce: 1. Install `l10n_in_reports` and set tax return periodicity. 2. Create multiple invoices in same month and name them like "INV/2026/8" to "INV/2026/12" (5 invoices) 3. Create GSTR-1 of that month and go to Document Summary. 4. The Sr. No from will be "INV/2026/10" and Sr. No To will be "INV/2026/9" Reason: Currently, while fetching the document list from `account.move`, we perform `min(name)` and `max(name)`. Now `name` is a varchar field and thin min and max functions compare them character by character, so naturally, if there are no zeros padded, among the sequences from "INV/2026/8" to "INV/2026/12", leaving the prefix, we got "/8", "/9", "/10", "/11", "/12" and string comparison for `min()` will give "/10" as the smallest and "/9" as the biggest for `max()`, which is misleading. Solution: This commit changes how we query for the min and max name. It now fetches min and max `sequence_number` instead of name and a max `name` of that group. This max name will help identify how many zeros are padded in the `sequence_number`, this will help generate an accurate sequence names for the document summary using the utility `_get_sequence_format_params` in `account.move`. task-6209721
This update fixes a performance issue within the Discuss module, specifically related to how it counts conversations. The change optimizes the query, resulting in faster response times and a smoother user experience. This improvement ensures the Discuss feature remains efficient and reliable for all users.
Original PR description
runbot-243772 https://github.com/odoo/odoo/pull/269111 Forward-Port-Of: odoo/enterprise#120067 Forward-Port-Of: odoo/enterprise#119886
This update allows WhatsApp event communications to utilize templates with the 'default recipient' option, expanding communication possibilities. Previously, a phone field was always required in WhatsApp templates, leading to validation errors when using this new feature. This change improves the usability and flexibility of WhatsApp event communications.
Original PR description
Allow WhatsApp event communications to use templates configured with the default recipient option. Steps to reproduce: - Install `whatsapp_event`. - Open any event. - Open the Communication tab. - Add a WhatsApp communication using a WhatsApp template that has the default recipient option enabled. Problem: The event communication constraint always expected a phone field on WhatsApp templates. Since templates can now be configured to use the default recipient, they may not define a phone field, causing an incorrect validation error when selected in an event communication. Solution: Adapt the event WhatsApp template constraint to allow templates that use the default recipient, while still requiring a phone field when the default recipient option is disabled.
This update ensures that the annual salary warning appears correctly on employee forms when using a fixed wage. Previously, this warning was only shown for certain wage types. This change improves accuracy and compliance by consistently displaying the warning for all fixed wage employees.
Original PR description
On employee's forms, only display the annual salary below threshold warning when the wage type of the version is set on fixed wage. task-6292248
This update removes a duplicate field, "Notice Period Real End", from employee and departure views. This simplifies the process of managing departure dates, especially when "Notice Respect" is set to "Partially", allowing the standard "Departure Date" to be edited.
Original PR description
Remove the redundant "Notice Period Real End" field from both the departure view wizard and employee view, as it duplicated "Departure Date". Now, when notice respect is set to "Partially", the standard "Departure Date" field becomes editable. Task: 6237636