Odoo Changelog — 2026-05-09

Saturday, May 9, 2026

12 changes · 19.0

Bug Fixes(12)

Resolved issues and error corrections

[FIX] planning: unlink working hours computation from progress bar

Enterprise19.0planningMEDIUM

This update resolves an issue where the Planning Gantt view wasn't accurately calculating working hours when the view wasn't grouped by resources. The fix ensures the total row correctly reflects employee working schedules, regardless of grouping settings. This improves the accuracy of project time tracking.

Original PR description

Issue: ---------------------------------------- In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours. Steps to reproduce:…

Issue:
----------------------------------------
In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours.

Steps to reproduce:
----------------------------------------
- Open Planning
- Remove the default group by resources
- Have at least a planning slot for a non-flexible employee
- The total row doesn't take the working schedule into account

Cause:
----------------------------------------
Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678))

Solution:
----------------------------------------
In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars.

opw-5507063

#planning#gantt#time tracking

[FIX] l10n_in_reports: fix import service RC in GSTR-3B

PR #116708

Enterprise19.0l10n_in_reportsMEDIUM

This update fixes a reporting issue related to Goods and Services Tax (GST) filings (GSTR-3B) in Russia. Previously, service reverse charge tax entries were missing from a key report table. Now, these entries are correctly included, ensuring accurate tax reporting and compliance.

Original PR description

Previously, journal items for import of services with reverse charge tax were shown only in table 4(A)(2) and not in table 3.1(d). However, since table 3.1(d) is meant for supplies liable to reverse charge, those entries should also be reported there.

With this commit, import of service reverse charge entries are now correctly included in table 3.1(d) as well.

#gst#russia#tax#reporting

[FIX] l10n_in_reports: fix GSTR2B reverse charge line amount sign

PR #116740

Enterprise19.0l10n_inMEDIUM

This update resolves an issue where tax reports (specifically for GSTR2B in Russia) were displaying incorrect amounts due to reversed sign handling. Now, bills are shown with positive values, and credit notes with negative values, ensuring accurate tax reporting and financial reconciliation.

Original PR description

In reverse charge taxes, tax tags are added on negative repartition lines, causing the amounts to appear with the opposite sign in reports. Due to this, credit notes were shown as positive amounts and bills as negative amounts.

This commit fixes the sign handling so that:
- bills are shown with positive amounts
- credit notes are shown with negative amounts

#tax#reporting#GSTR2B#Russia

[FIX] iot: handlers download WIoT

PR #116744

Enterprise19.0iot

This update resolves an issue where IoT Box handler downloads were incompatible due to a change in version formatting. In Odoo 19.0, WIoT Boxes now correctly download handlers based on their database version and system type, ensuring compatibility and preventing potential driver mismatches. This ensures stable operation of IoT integrations.

Original PR description

Since odoo/odoo#263089, Virtual IoT Boxes use
the YYYYMMDD version format, making them match
the "stable IoT Box" regex in the `get_handlers`
controller.

This check is meant not to provide default handlers for clients developing their own drivers, as
versions could mismatch (more details in odoo/enterprise#263089).

In v19.0, WIoT Boxes are not "stable", as they still checkout the db's version and download handlers from it: we then add a check on the system type (Windows/Linux) in addition to the one on the version.

#iot#compatibility#handler

[FIX] l10n_us_hr_payroll_state_calculation: prevent CO state income tax from being positive

PR #116653

Enterprise19.0l10n_us_hr_payroll

This update corrects a bug in the payroll calculation for Colorado-based employees. Previously, the CO State Income Tax could show a positive value, which incorrectly indicated a refund instead of a withholding. This fix aligns with established payroll tax principles, ensuring accurate withholding calculations.

Original PR description

## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).

opw-5999856

Forward-Port-Of: odoo/enterprise#116305
Forward-Port-Of: odoo/enterprise#112724

#payroll#tax#usa

[FIX] sale_lazada: allow non-storable products when not synced

PR #116543

Enterprise19.0sale_lazada

This update removes a restriction that previously required Lazada products to be 'storable'. When stock synchronization with Lazada is turned off (as is common), tracking stock isn't needed, so this restriction is no longer necessary. This simplifies product setup for Lazada listings.

Original PR description

Lazada items previously required products to be of type 'storable'. This restriction is unnecessary when stock synchronization is disabled, since no stock tracking is performed in that case.

opw-6173986

#Lazada#Product Listing#Stock Synchronization

[FIX] account_reports: fix AccessError on shared accounts

PR #115454

Enterprise19.0accountMEDIUM

This update resolves a bug that prevented users from posting journal entries using accounts shared between companies when an open audit period was active. The fix ensures proper access controls are enforced, allowing users in Company B to correctly record transactions linked to shared accounts during audits. This improves reporting accuracy and prevents disruptions to financial processes.

Original PR description

Posting a journal entry using an account shared between multiple
companies during an open audit period raises an AccessError.

Steps to reproduce:
- Configure an account to be shared between Company A and Company B.
  - Add Company A and Company B in 'Companies'
  - In the mapping tab, add a code for each company
- In Company A, create a tax audit for a specific fiscal period.
- Switch to Company B and keep just Company B selected.
- Create and post a journal entry using the shared account within the
  same date period.

Issue: An AccessError is raised when posting the move. The system
attempts to check the status of the audit records linked to the
shared account, to which the user in Company B does not have read access.

opw-5993450

#accounting#reporting#audit#shared accounts

[FIX] account_budget: prevent duplicates in budget report

PR #116724

Enterprise19.0account

The budget report now accurately displays data without duplicate analytic lines. This change addresses an issue caused by a recent performance optimization of the budget report query, which inadvertently created duplicate entries. The fix ensures data integrity and reliable reporting.

Original PR description

#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item…

#### Issue:
The budget report displays duplicate analytic lines.

#### Steps to reproduce:
In a new company:
- Create a budget with one budget line (Analytic Account A).
- Create one analytic item (linked to Analytic Account A).
- Open the budget report and remove the default "open budget" filter.
Duplicate amounts appear in the pivot view and duplicate lines appear in the list view.

#### Cause:
In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report.

#### Fix:
Use three separate queries, each with specific filter conditions to guarantee unique results:
Q1 - Analytic lines with no matching budget line.
Q2 - Analytic lines matched to a budget line with no company (null-company).
Q3 - Analytic lines matched to a company-specific budget line.

OPW-6051696

Forward-Port-Of: odoo/enterprise#116612

#reporting#budget#analytics

[FIX] website_sale_renting_planning: avoid shop crash with public time off

PR #116809

Enterprise19.0website_sale_renting_planningHIGH

This update resolves a critical issue where the rental website would crash when overlapping closed days and public time off periods were selected. The fix simplifies the availability check to focus solely on time ranges, ensuring a stable and reliable rental availability display for customers. This improves the user experience and prevents lost sales.

Original PR description

Steps to reproduce:
- Install website_sale_renting_planning.
- Create a rental service product linked to a planning role.
- Enable Sync Shifts and Rental Orders on that role.
- Add a two-day public time off on the working calendar.
- Open the product on the website with overlapping dates.

Current behavior:
The shop crashes when the selected dates overlap a closed day and a public time off.

Expected behavior:
The website should show rental availability without crashing when both cases overlap.

Issue:
The availability flow mixed two kinds of calendar data while it only needed time ranges, so the overlap broke the website flow.

Fix:
Keep the unavailability check focused on time ranges for closed days and public time off so both cases can be combined safely.

Ref:
odoo/enterprise#98165
odoo/enterprise#102070
odoo/enterprise#102076

task-6164218

Forward-Port-Of: odoo/enterprise#115480

#rental#availability#website#bug fix

[FIX] sale_timesheet_enterprise: check menu exists

PR #116783

Enterprise19.0sale_timesheet_enterprise

This update resolves an issue where removing menus in the Enterprise version of Odoo would cause a system error. The fix ensures the system properly checks for the existence of menus before attempting to load them, preventing the error and maintaining stability. This ensures a smoother user experience for Enterprise users.

Original PR description

to reproduce issue:
1) make a database in 18.3 .
2) delete the menu/menus.
3) it will fail  on _load_menus_blacklist.

Forward-Port-Of: odoo/enterprise#116498

#bug#stability#enterprise

[FIX] industry_fsm : properly enable rotting in My Tasks

PR #116530

Enterprise19.0industry_fsm

This update resolves a technical issue where a 'rotting' button was incorrectly displayed in the My Tasks Kanban view. The fix corrects a misconfiguration in how the application inherited functionality, ensuring the button only appears when intended. This prevents unexpected behavior and maintains a stable user experience.

Original PR description

# How to reproduce - Go to All Tasks > All Tasks - Select the Kanban View - Edit the settings of the stage "New" - Set the value of "Days to rot" to a negative number (e.g. -4) - Go to My Tasks >…

# How to reproduce
- Go to All Tasks > All Tasks
- Select the Kanban View
- Edit the settings of the stage "New"
- Set the value of "Days to rot" to a negative number (e.g. -4)
- Go to My Tasks > Tasks
- Click on the red button displaying the number of task rotting

# The problem
We get a traceback

# Cause
When we click on that red, button, we call this function : https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/mail/static/src/js/rotting_mixin/rotting_kanban_header.js#L11-L13

This `toggleFilterRotten` function is patched in `progressBarState` by the `RottingKanbanController` class:
https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/mail/static/src/js/rotting_mixin/rotting_progress_bar_hook.js#L1-L10 https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/mail/static/src/js/rotting_mixin/rotting_kanban_controller.js#L6-L11

But the `FsmMyTaskKanbanController`, which the specific controller of the My Tasks view in the Field Service app does not inherit from the `RottingKanbanController` class : https://github.com/odoo/enterprise/blob/32496b52d8333f68603bba6a0c1af3ed42f59287/industry_fsm/static/src/views/fsm_my_task_kanban/fsm_my_task_kanban_controller.js#L5

Then why was the rotting button even available ? That's because `fsmMyTaskKanbanView ` inherit from `projectTaskKanbanView`, which header inherit from `RottingKanbanController` : https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/project/static/src/views/project_task_kanban/project_task_kanban_header.js#L4-L9

opw-6186575

#kanban#my tasks#field service

[FIX] project_enterprise: fix gantt unavailabilities for flexible employees

PR #116843

Enterprise19.0project_enterprise

This update corrects a visual issue in the Project Gantt view where flexible employees were incorrectly marked as unavailable during weekends and off-hours. The fix ensures that flexible employees only appear unavailable when they have approved leaves or public holidays, improving the accuracy of project timelines.

Original PR description

Steps to Reproduce
---
- Assign a flexible working schedule to an employee (no leaves)
- Open Project > Tasks > Gantt view grouped by Assignee
- The employee's weekends and off-hours are grayed out

Current Behavior
---
Flex employees with no approved leaves in the viewed date range have incorrect grayed-out days in the Project Gantt view.

Expected Behavior
---
Flex employees should have no grayed-out days except approved leaves and public holidays.

Issue
---
When a flex employee has no leaves in the viewed period, `_get_unavailable_intervals()` returns an empty dict for that resource. `_gantt_unavailability()` then falls back to `company_leaves`, producing incorrect gray intervals. The same case is already handled in `planning` (ref PR), but `project_enterprise` was not covered.

Fix
---
Add a guard in `_gantt_unavailability()` to return no unavailabilities for flexible resources absent from `leaves_mapping`.

Related : https://github.com/odoo/odoo/commit/5f1cd39944134ffa2c30c331f8a5daca56446d78 
task - 5063071

Forward-Port-Of: odoo/enterprise#113247

#gantt#flexible employees#availability

Issue: ---------------------------------------- In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours. Steps to reproduce: ---------------------------------------- - Open Planning - Remove the default group by resources - Have at least a planning slot for a non-flexible employee - The total row doesn't take the working schedule into account Cause: ---------------------------------------- Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678)) Solution: ---------------------------------------- In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars. opw-5507063

Previously, journal items for import of services with reverse charge tax were shown only in table 4(A)(2) and not in table 3.1(d). However, since table 3.1(d) is meant for supplies liable to reverse charge, those entries should also be reported there. With this commit, import of service reverse charge entries are now correctly included in table 3.1(d) as well.

In reverse charge taxes, tax tags are added on negative repartition lines, causing the amounts to appear with the opposite sign in reports. Due to this, credit notes were shown as positive amounts and bills as negative amounts. This commit fixes the sign handling so that: - bills are shown with positive amounts - credit notes are shown with negative amounts

Since odoo/odoo#263089, Virtual IoT Boxes use the YYYYMMDD version format, making them match the "stable IoT Box" regex in the `get_handlers` controller. This check is meant not to provide default handlers for clients developing their own drivers, as versions could mismatch (more details in odoo/enterprise#263089). In v19.0, WIoT Boxes are not "stable", as they still checkout the db's version and download handlers from it: we then add a check on the system type (Windows/Linux) in addition to the one on the version.

## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll* (`l10n_us_hr_payroll`) 2. Set the current company's State to Colorado 3. Create an employee and a contract - Wage: $0 - (Set the contract's status to *Running*) - (In the payroll tab) State Withholding Allowance: $1000 4. Create a Payslip for the employee - Structure: *"United States: Regular Pay"* 5. Compute Sheet 6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value** ## Justification This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280: > *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."* ## Note to reviewer The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one). opw-5999856 Forward-Port-Of: odoo/enterprise#116305 Forward-Port-Of: odoo/enterprise#112724

Lazada items previously required products to be of type 'storable'. This restriction is unnecessary when stock synchronization is disabled, since no stock tracking is performed in that case. opw-6173986

Posting a journal entry using an account shared between multiple companies during an open audit period raises an AccessError. Steps to reproduce: - Configure an account to be shared between Company A and Company B. - Add Company A and Company B in 'Companies' - In the mapping tab, add a code for each company - In Company A, create a tax audit for a specific fiscal period. - Switch to Company B and keep just Company B selected. - Create and post a journal entry using the shared account within the same date period. Issue: An AccessError is raised when posting the move. The system attempts to check the status of the audit records linked to the shared account, to which the user in Company B does not have read access. opw-5993450

#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item (linked to Analytic Account A). - Open the budget report and remove the default "open budget" filter. Duplicate amounts appear in the pivot view and duplicate lines appear in the list view. #### Cause: In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report. #### Fix: Use three separate queries, each with specific filter conditions to guarantee unique results: Q1 - Analytic lines with no matching budget line. Q2 - Analytic lines matched to a budget line with no company (null-company). Q3 - Analytic lines matched to a company-specific budget line. OPW-6051696 Forward-Port-Of: odoo/enterprise#116612

Steps to reproduce: - Install website_sale_renting_planning. - Create a rental service product linked to a planning role. - Enable Sync Shifts and Rental Orders on that role. - Add a two-day public time off on the working calendar. - Open the product on the website with overlapping dates. Current behavior: The shop crashes when the selected dates overlap a closed day and a public time off. Expected behavior: The website should show rental availability without crashing when both cases overlap. Issue: The availability flow mixed two kinds of calendar data while it only needed time ranges, so the overlap broke the website flow. Fix: Keep the unavailability check focused on time ranges for closed days and public time off so both cases can be combined safely. Ref: odoo/enterprise#98165 odoo/enterprise#102070 odoo/enterprise#102076 task-6164218 Forward-Port-Of: odoo/enterprise#115480

# How to reproduce - Go to All Tasks > All Tasks - Select the Kanban View - Edit the settings of the stage "New" - Set the value of "Days to rot" to a negative number (e.g. -4) - Go to My Tasks > Tasks - Click on the red button displaying the number of task rotting # The problem We get a traceback # Cause When we click on that red, button, we call this function : https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/mail/static/src/js/rotting_mixin/rotting_kanban_header.js#L11-L13 This `toggleFilterRotten` function is patched in `progressBarState` by the `RottingKanbanController` class: https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/mail/static/src/js/rotting_mixin/rotting_progress_bar_hook.js#L1-L10 https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/mail/static/src/js/rotting_mixin/rotting_kanban_controller.js#L6-L11 But the `FsmMyTaskKanbanController`, which the specific controller of the My Tasks view in the Field Service app does not inherit from the `RottingKanbanController` class : https://github.com/odoo/enterprise/blob/32496b52d8333f68603bba6a0c1af3ed42f59287/industry_fsm/static/src/views/fsm_my_task_kanban/fsm_my_task_kanban_controller.js#L5 Then why was the rotting button even available ? That's because `fsmMyTaskKanbanView ` inherit from `projectTaskKanbanView`, which header inherit from `RottingKanbanController` : https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/project/static/src/views/project_task_kanban/project_task_kanban_header.js#L4-L9 opw-6186575

Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out Current Behavior --- Flex employees with no approved leaves in the viewed date range have incorrect grayed-out days in the Project Gantt view. Expected Behavior --- Flex employees should have no grayed-out days except approved leaves and public holidays. Issue --- When a flex employee has no leaves in the viewed period, `_get_unavailable_intervals()` returns an empty dict for that resource. `_gantt_unavailability()` then falls back to `company_leaves`, producing incorrect gray intervals. The same case is already handled in `planning` (ref PR), but `project_enterprise` was not covered. Fix --- Add a guard in `_gantt_unavailability()` to return no unavailabilities for flexible resources absent from `leaves_mapping`. Related : https://github.com/odoo/odoo/commit/5f1cd39944134ffa2c30c331f8a5daca56446d78 task - 5063071 Forward-Port-Of: odoo/enterprise#113247