Daily updates from Odoo
Saturday, August 30, 2025
6 changes · saas-18.3
Resolved issues and error corrections
Fixed an issue where public holidays spanning several days appeared as only one blocked day in calendar views for employees using flexible work schedules. This makes holiday calendars match the actual time-off restrictions, reducing confusion for employees and managers.
Original PR description
**Issue**: Multi-day public holidays only display as single days in calendar views when using flexible working schedules. A 3-day holiday appears as only 1 day blocked, though time-off requests are still correctly prevented for all 3 days. **Cause:** In `_get_unusual_days()`, the implementation for flexible schedules only captures the start date of each leave interval https://github.com/odoo/odoo/blob/132938929d46c8248a9e3a7e2972174ae38eacfa/addons/resource/models/resource_calendar.py#L683-L685 **Steps to reproduce:** 1. Configure a flexible working schedule for an employee or company 2. Go to Time Off > Public Holidays 3. Create a 3 day public holiday 4. Check Time Off calendar view Only 1 day appears blocked instead of all 3 days opw-4997757 Forward-Port-Of: odoo/odoo#224668
This fix ensures records that have been deleted in the mail system are no longer returned to business logic during the brief deletion process. This reduces the risk of crashes and inconsistent data when related fields or automated updates process those records.
Original PR description
Before this commit, business code could leak records that are soft deleted, i.e. the representation of the record is still in the store but conceptually this record is deleted. These soft-deleted…
Before this commit, business code could leak records that are soft deleted, i.e. the representation of the record is still in the store but conceptually this record is deleted. These soft-deleted records are present in the code for a very short time, just enough time to warn business code in the onDelete() hooks. The problem for Model.records and Model.get() to return these records, is that the business code thinks these records are not deleted, which can lead to misuses and crashes. For example: if a computed field returns this soft-deleted record, then the field value has this soft-deleted record. When the record is hard-deleted, this field will be recomputed, but when diffing with its old this will crash because it will still have a trace of the record in the internal code. This commit fixes the issue by removing the record from Model.records when soft-deleted, so that Model.records and Model.get() doesn't return this record. The onDelete() hooks will returned the soft-deleted like before because the deleted records are stored in the data queue of the hooks. This solution also solves another problem: if a record is deleted and there's an immediate side-effect computed field to insert this record, the previous implementation would hard-delete the record at the end which is wrong: the record should be deleted but the insert part should apply, thus the resulting record is a fresh one with same identity but only partial data from the insert. All other field values must be lost from the deletion. The changes in this commit also fixes this issue. Commit also fixes issue for `.exists()` that should be `false` for soft-deleted records. Task-4860196 Forward-Port-Of: odoo/odoo#224485
This fixes an issue in Point of Sale loyalty rewards where customers could receive the wrong number of free products when multiple free-product rewards were available. The correction helps ensure promotions are applied accurately at checkout and reduces pricing or fulfillment mistakes.
Original PR description
Before this commit, when there were multiple reward lines for free products, adding a combination of those products would result in incorrect claimed free product quantities. opw-4975059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224683 Forward-Port-Of: odoo/odoo#222780
This fix keeps the selected customer attached to the current point of sale order when staff open the All Orders view from the customer list. It avoids unnecessary re-selection and helps maintain a smoother checkout workflow.
Original PR description
Before this commit, opening the All Orders from the partner list would reset the selected partner. As a result, the user had to reselect the partner after returning, which disrupted the workflow. opw-4972314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224679 Forward-Port-Of: odoo/odoo#222507
A payroll accounting test was updated so it no longer depends on the current year. This prevents avoidable test failures in 2026 and helps keep maintenance and release validation predictable.
Original PR description
Some tests will fail in 2026. This adds a freeze time to prevent this failing. Task: 5034173 Forward-Port-Of: odoo/enterprise#92983
Payroll users can now change salary rule colors reliably from both the Salary Rules screen and the salary rule pop-up opened from Salary Structures. This keeps rule previews visually accurate, reducing confusion when managing payroll rules.
Original PR description
Steps to Produce: - open payroll app - Go to Salary Rules or go to Salary Structures and open any salary rule. - try to change color of any rule. issue: - The color does not change in the Salary Rules. - Additionally, styles do not apply in the salary rule pop-up accessed through Salary Structures. Fix: - Instead of changing the color with formrenderer, a custom widget was created to apply styles directly to the field. opw-4716810 task-4774448 Forward-Port-Of: odoo/enterprise#83514