Daily updates from Odoo
Monday, March 2, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where the scheduling dialog was incorrectly filtering out unscheduled shifts for resources with no existing assignments. The fix removes a default filter, ensuring planners can now see and assign all relevant shifts, improving scheduling efficiency. This change impacts the Planning Gantt view.
Original PR description
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue…
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue ----- A previous change keeps the clicked resource in the dialog context; the Gantt model turns it into a default search filter, so only shifts already linked to that resource are shown. Unassigned shifts are therefore hidden, preventing planners from assigning them by role or availability. Current Behaviour ----------------- The Plan dialog is always filtered by `resource_id`, which returns no results for unscheduled resources, even when they have the right roles. Expected Behaviour ------------------ The dialog should list all unscheduled shifts that match the resource’s roles, or every unscheduled shift if the resource has no roles, while still preserving full context for scheduling once a shift is selected. Fix --- Remove the automatic resource filter from the dialog context in `getSelectCreateDialogProps()`. This prevents the unwanted search restriction; role defaults remain, so the dialog now displays the correct shifts. Task-4922525 Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d
This update fixes inconsistencies between rental orders and planning slots, ensuring dates are always synchronized. It also corrects issues with quantity adjustments and resource allocation, preventing conflicts and improving data accuracy for rental scheduling. This enhances the reliability of our rental planning process.
Original PR description
## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates Before this commit, it was possible to have `Planning Slots` with `Sync Shifts and Rental Orders` whose dates…
## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates Before this commit, it was possible to have `Planning Slots` with `Sync Shifts and Rental Orders` whose dates were different from the `Rental order`. This commit makes sure that all dates are always synced: - If the `Rental Order` dates are changed then all `Planning Slots`' dates changed to the new dates. - If a `Planning Slot` dates have changed then all other `Planning Slots` and the `Rental Order` Dates are changed to the new dates. ## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots Before this commit, adding/removing a `Planning Slot` would not change the `SOL quantity` and changing the `SOL quantity` would not add/remove `Planning Slots` unless all slots are being deleted. This commit makes sure that when the `SOL quantity` is changed, the number of `Planning Slots` is changed accordingly, and if a Planning Slot` was added/removed, the `SOL quantity` would update accordingly. Note: The new sync behaviour from `SOL quantity` is ignored for `Products` with `hour UOM` because it is not clear yet how to update the `Planning Slots` if the new quantity of hours doesn't span a full rental interval. ## [FIX] sale_renting_planning: fix set multiple slots to resources Before this commit, adding multiple `Planning Slots` at the same time with the same `Role` can assign them to the same `Resource` even if they conflict with each other. This commit makes sure that when adding multiple `Planning Slots` none of them would conflict with each other after being added. task-5187356
This update fixes a problem where archived employees caused errors when managing appraisal plans. The system now correctly clears appraisal dates upon archiving, preventing date conflicts and ensuring accurate appraisal plan settings for active employees. This improves the stability and usability of the appraisal management feature.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#108990 Forward-Port-Of: odoo/enterprise#100437
This update resolves an issue where the cash drawer wasn't automatically opening when the cash details popup was accessed in the Italian Point of Sale (POS) system. The fix ensures that the cash drawer opens consistently when this popup is opened, regardless of whether the POS session is open or closed. This improves the user experience for Italian POS operations.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094 Forward-Port-Of: odoo/enterprise#109057 Forward-Port-Of: odoo/enterprise#107987
This update corrects a recent change that was preventing the accurate calculation of contractual annual wages in the Swiss payroll module. The annual wage is now correctly factored into payroll calculations, ensuring accurate tax and social security deductions for Swiss employees. This ensures compliance with Swiss tax regulations.
This update resolves an error that occurred when generating payslips for employees with contract changes. The fix ensures the system uses the employee's initial contract start date for accurate year calculations, preventing errors related to holiday table lookups. This improves the reliability of payroll processing.
Original PR description
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change Steps to reproduce: 1. Install l10n_mx and l10n_mx_hr_payroll modules…
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change
Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown
Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0
Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked
opw-5931355This update corrects a bug that caused duplicate Dimona activities to be created in the payroll system. Previously, running automated updates resulted in multiple activity records for employees. Now, the system checks for existing activities before creating new ones, ensuring accurate payroll calculations and avoiding data inconsistencies.
Original PR description
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium employee > new > payroll > contract > start_date: any date (this should create a first dimona activity) settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually `_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one. We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it. [tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380)
This update corrects a technical issue that could cause inconsistencies in the calculations for employee payslips. The change ensures that all payroll line data remains synchronized, leading to more accurate and reliable payroll processing. This resolves a potential problem impacting payroll accuracy.
Original PR description
Forward-Port-Of: odoo/enterprise#108983 Forward-Port-Of: odoo/enterprise#108729