Daily updates from Odoo
Saturday, May 9, 2026
27 changes
5 changes
Resolved issues and error corrections
This update resolves an issue that caused errors when closing all conversations in the chat application. The fix prevents a re-render from triggering a traceback by adding optional chaining to access channel data. This ensures a smoother and more reliable chat closing experience for users.
Original PR description
When closing all conversations from ChatHub, setting `confirmCloseResolver` to `null` in `_canClose()` starts a re-render of ChatHub and ChatWindow, but the render does not complete and `requestClose()` continues. During this flow, `close()` deletes the chat window, and when the re-render of ChatWindow actions continues, the call and camera-call action name callbacks try to access `channel.hasRtcSessionActive`, causing a traceback. This commit fixes the issue by adding optional chaining on channel in the name functions of the call and camera-call thread actions. Task-[6120744](https://www.odoo.com/odoo/project/1519/tasks/6120744) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260308
This update fixes an issue where some UBL invoices were being processed incorrectly. The system now intelligently checks for a specific 'CustomizationID' to determine if an invoice is a BIS3 format, improving the accuracy of invoice processing. A fallback mechanism remains in place for unknown formats.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263527 Forward-Port-Of: odoo/odoo#263285
This update resolves a bug where users with limited permissions experienced errors when accessing task details within subscription timesheets. The fix involves simplifying data retrieval to prevent privilege-related access issues, ensuring smoother operation for all users.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update fixes a minor usability issue in the Helpdesk module. Previously, users couldn't easily delete a stage in a Kanban view due to a missing keyboard shortcut. This commit adds the necessary shortcut, streamlining the stage deletion process and improving user efficiency.
Original PR description
Before this commit, when the user tries to delete a kanban column in ticket kanban view when the group by is stage_id. A pop-up appears when there is at least one ticket in that stage to notify the user it would be better to archive the stage or remove all tickets from that stage before deleting it. The Confirm and Discard buttons of that wizard does not have keyboard shortcut as the other discard button in the other views/wizards. This commit makes sure the keyboard shortcut is correctly assigned to those buttons. task-4885677 Forward-Port-Of: odoo/enterprise#116297 Forward-Port-Of: odoo/enterprise#89141
This update fixes an issue where portal users couldn't view timesheet information associated with tasks. The change adjusts how timesheet visibility is managed within the system, aligning with a recent portal refactor. Now, portal users correctly see the timesheets linked to their tasks.
Original PR description
Steps to reproduce: - Install `website_timesheet` - Enable timesheets from website - Share a task with a portal user - Log in as the portal user - Open the tasks on the portal Issue: The Timesheets is not visible. Root cause: Earlier, portal card visibility and existence were controlled directly in the QWeb template. After the portal refactoring, their visibility and existence are now managed by `portal.entry` records. Fix: Determine timesheet visibility using the corresponding `portal.entry` record. task-5455588 Forward-Port-Of: odoo/odoo#241832
4 changes
Resolved issues and error corrections
This update fixes an issue where some UBL invoices were being incorrectly processed. The change ensures that invoices with a valid CustomizationID are prioritized, improving the accuracy of UBL invoice handling. A fallback mechanism remains in place for unexpected invoice formats.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263527 Forward-Port-Of: odoo/odoo#263285
This update resolves an issue where users with limited permissions were encountering errors when accessing task details within subscription timesheets. The fix involves bypassing data fetching to prevent privilege-related access problems, ensuring smoother operation for users with restricted access.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update fixes a minor usability issue in the Helpdesk module. Previously, users couldn't easily delete stages in the ticket Kanban view using keyboard shortcuts. This commit adds keyboard shortcuts to the confirmation and discard buttons, streamlining the stage deletion process and improving efficiency.
Original PR description
Before this commit, when the user tries to delete a kanban column in ticket kanban view when the group by is stage_id. A pop-up appears when there is at least one ticket in that stage to notify the user it would be better to archive the stage or remove all tickets from that stage before deleting it. The Confirm and Discard buttons of that wizard does not have keyboard shortcut as the other discard button in the other views/wizards. This commit makes sure the keyboard shortcut is correctly assigned to those buttons. task-4885677 Forward-Port-Of: odoo/enterprise#89141
This update resolves an issue where a 'rotting' button was incorrectly displayed in the My Tasks view due to a misconfiguration in the Field Service app. The fix ensures that the button only appears when a stage is set to a negative 'Days to rot' value, preventing unexpected behavior and improving the 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 Forward-Port-Of: odoo/enterprise#116530
4 changes
Resolved issues and error corrections
This update fixes an issue where some UBL invoices were being processed incorrectly. The change ensures that invoices with a valid CustomizationID are prioritized, improving the accuracy of invoice processing. A fallback mechanism remains in place for unknown UBL formats to maintain compatibility.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263527 Forward-Port-Of: odoo/odoo#263285
This update resolves an issue where portal users couldn't see timesheets associated with tasks. The fix adjusts how timesheet visibility is determined, reflecting changes made during a recent portal system update. Now, portal users will correctly see timesheet information for shared tasks.
Original PR description
Steps to reproduce: - Install `website_timesheet` - Enable timesheets from website - Share a task with a portal user - Log in as the portal user - Open the tasks on the portal Issue: The Timesheets is not visible. Root cause: Earlier, portal card visibility and existence were controlled directly in the QWeb template. After the portal refactoring, their visibility and existence are now managed by `portal.entry` records. Fix: Determine timesheet visibility using the corresponding `portal.entry` record. task-5455588
This update fixes an issue where tax reports (specifically for GSTR2B in India) were displaying incorrect signs for bills and credit notes. The change ensures bills show positive amounts and credit notes show negative amounts, aligning with standard accounting practices and improving report accuracy.
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 Forward-Port-Of: odoo/enterprise#116740
This update resolves an issue where a 'rotting' button was incorrectly displayed in the My Tasks Kanban view, causing a traceback. The fix corrects a misconfiguration in how the system tracks task aging, ensuring accurate reporting of overdue tasks within the Field Service app. This prevents potential confusion and ensures data integrity.
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 Forward-Port-Of: odoo/enterprise#116530
1 change
Resolved issues and error corrections
This update resolves an issue where the Sale Timesheet module would fail to load if certain menus were deleted from the database. The fix ensures the module checks for the existence of these menus before proceeding, preventing errors and maintaining stability. This improves the reliability of the Sale Timesheet functionality.
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
2 changes
Resolved issues and error corrections
The budget report now accurately displays financial data without duplicate analytic lines. This issue stemmed from a recent performance optimization of the budget report query, which inadvertently introduced duplicate entries. The fix ensures unique and reliable reporting by restructuring the underlying queries.
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
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…
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
3 changes
Resolved issues and error corrections
This update resolves intermittent errors occurring during tests for the planning field service's geolocation functionality. These errors were causing unreliable test results. The fix ensures the geolocation tests are now consistently reliable, improving the stability of the planning field service.
Original PR description
This commits aims to resolve the undeterministic failures of the planning field service geolocation tests. Forward-Port-Of: odoo/enterprise#116176
This update resolves a bug where users with limited permissions were encountering errors when modifying subscription timesheet tasks. The fix involves simplifying data fetching to prevent privilege-related access issues, ensuring smoother operation for users with restricted access.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update fixes a minor usability issue in the Helpdesk module. Previously, users were prompted to archive or clear stages before deleting them, but lacked keyboard shortcuts for navigation. Now, keyboard shortcuts are correctly assigned to the confirmation and discard buttons in the stage deletion wizard, streamlining the process.
Original PR description
Before this commit, when the user tries to delete a kanban column in ticket kanban view when the group by is stage_id. A pop-up appears when there is at least one ticket in that stage to notify the user it would be better to archive the stage or remove all tickets from that stage before deleting it. The Confirm and Discard buttons of that wizard does not have keyboard shortcut as the other discard button in the other views/wizards. This commit makes sure the keyboard shortcut is correctly assigned to those buttons. task-4885677 Forward-Port-Of: odoo/enterprise#116297 Forward-Port-Of: odoo/enterprise#89141
7 changes
Resolved issues and error corrections
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.
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#112724This 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
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
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
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
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…
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
1 change
Resolved issues and error corrections
This update fixes an issue where flexible employees were incorrectly shown as unavailable in the Project Gantt chart. The change ensures that flexible employees without scheduled leaves are not grayed out, aligning the Gantt chart with their actual working hours. This improves 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…
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