Previously, computing warning_employee_rate fetched all analytic lines associated with projects.task_ids to check if any employee lacked a sale_order_line in project.sale.line.employee.map.

This approach had two major flaws:

	1- Iterating over all accessible tasks is highly inefficient for
	large projects, especially since many tasks do not even have
	associated analytic lines.

	2- Fetching analytic lines blindly by task_id could pull in lines
	linked to a completely different project_id adding performance issues.

**Solution**:
Since the compute method for the `project_id` field for the `account.analytic.line` model is making sure that the field `project_id` equal the project for the task, then we can remove the domain matching for the `task_id`.

We now can replace the `_read_group` with a simple SQL query, filtering out the unmapped projects directly.

The benchmark done below was on a database that had around 10M analytic lines, 2K `project_sale_line_employee_map` records and 1M tasks with the top 80 projects in terms of the number of `analytic.lines` + projects that had the most records in the `project_sale_line_employee_map`.
| Before | After |
| :--- | :--- |
| 33.0s | 170.0ms |

Forward-Port-Of: odoo/odoo#260935

Steps to reproduce:
- Ensure:
  - Marc Demo is a “Project” admin
  - All projects have “allow_task_dependencies” set to false. This will remove the “Use Task Dependencies” group from Role / User, so the order of these steps is important
  - Add Role / User implies “Use Task Dependencies”
- Sign in as Marc Demo and attempt to create a new project from the “Product Launch Campaign” template

Description:
`_inverse_allow_task_dependencies()` uses `_check_project_group_with_field()` to determine if task dependency features should be enabled/disabled by modifying the `hidden` field on `mail.message.subtype` records (e.g. `mt_task_waiting`). This occurs whenever a project is created from templates. However write access to these records are restricted to admins, so we need elevated permissions when attempting to do so. Without `sudo`, access errors are thrown if non-admin users attempt to create projects under specific scenarios (i.e. when `_check_project_group_with_field()` adds or removes a group from the user base group).

The search within `_check_project_group_with_field()` also needs elevated permissions to prevent false negatives. Without `sudo`, this search is restricted by the user's record rules. If the user cannot see the specific projects where dependencies are active, the system may incorrectly assume that no projects use these dependencies, and will forcefully unlink the dependency group from `base.group_user`, breaking the feature globally for all users.

Applying `.sudo()` to the subtype modification and the project search ensures standard users can create projects from templates without crashing and prevents the accidental global removal of the dependency group.

opw-6099425

Forward-Port-Of: odoo/odoo#263203
Forward-Port-Of: odoo/odoo#258996

During a previous fix (https://github.com/odoo/odoo/pull/206158), fallback values were added for an explicit `email_to` if the default email template for the abandonned cart was missing them.

But since (https://github.com/odoo/odoo/pull/172714), the template uses `use_default_to` == True, which will compute the default partner and add them to `partner_ids` of the `mail.mail` record.

So the old bug of "abandoned cart email is sent twice" reappered: the if condition fails to account for `use_default_to` being set, so the partner email is set explicitly on `email_to` AND referenced in `partner_ids`, which de-facto sends the email twice to the customer on the sales order.

## FIX:
We account for `use_default_to` in the if condition before adding the fallback.

How to reproduce:
1) Setup a database with demo data and website_sale 
2) Visit the shop as a visitor, add stuff to your cart 
3) Sign up for portal access and add new stuff to cart (will attribute SO to new portal account)
4) Wait for the abandoned cart email to trigger (can be forced by playing with `cart_recovery_email_sent`: false,`is_abandoned_cart`: true and triggering the CRON) -> mail is sent twice to the customer

Remarks:
- changed the unit test to actually capture the generated `mail.mail` and apply some asserts on it

OPW-6134731

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#261039

Steps to reproduce:
- Ensure:
  - Marc Demo is a “Project” admin
  - All projects have “allow_task_dependencies” set to false. This will remove the “Use Task Dependencies” group from Role / User, so the order of these steps is important
  - Add Role / User implies “Use Task Dependencies”
- Sign in as Marc Demo and attempt to create a new project from the “Product Launch Campaign” template

Description:
`_inverse_allow_task_dependencies()` uses `_check_project_group_with_field()` to determine if task dependency features should be enabled/disabled by modifying the `hidden` field on `mail.message.subtype` records (e.g. `mt_task_waiting`). This occurs whenever a project is created from templates. However write access to these records are restricted to admins, so we need elevated permissions when attempting to do so. Without `sudo`, access errors are thrown if non-admin users attempt to create projects under specific scenarios (i.e. when `_check_project_group_with_field()` adds or removes a group from the user base group).

The search within `_check_project_group_with_field()` also needs elevated permissions to prevent false negatives. Without `sudo`, this search is restricted by the user's record rules. If the user cannot see the specific projects where dependencies are active, the system may incorrectly assume that no projects use these dependencies, and will forcefully unlink the dependency group from `base.group_user`, breaking the feature globally for all users.

Applying `.sudo()` to the subtype modification and the project search ensures standard users can create projects from templates without crashing and prevents the accidental global removal of the dependency group.

opw-6099425

Forward-Port-Of: odoo/odoo#258996

# 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

Previously, computing warning_employee_rate fetched all analytic lines associated with projects.task_ids to check if any employee lacked a sale_order_line in project.sale.line.employee.map.

This approach had two major flaws:

	1- Iterating over all accessible tasks is highly inefficient for
	large projects, especially since many tasks do not even have
	associated analytic lines.

	2- Fetching analytic lines blindly by task_id could pull in lines
	linked to a completely different project_id adding performance issues.

**Solution**:
Since the compute method for the `project_id` field for the `account.analytic.line` model is making sure that the field `project_id` equal the project for the task, then we can remove the domain matching for the `task_id`.

We now can replace the `_read_group` with a simple SQL query, filtering out the unmapped projects directly.

The benchmark done below was on a database that had around 10M analytic lines, 2K `project_sale_line_employee_map` records and 1M tasks with the top 80 projects in terms of the number of `analytic.lines` + projects that had the most records in the `project_sale_line_employee_map`.
| Before | After |
| :--- | :--- |
| 33.0s | 170.0ms |

Forward-Port-Of: odoo/odoo#260935

During a previous fix (https://github.com/odoo/odoo/pull/206158), fallback values were added for an explicit `email_to` if the default email template for the abandonned cart was missing them.

But since (https://github.com/odoo/odoo/pull/172714), the template uses `use_default_to` == True, which will compute the default partner and add them to `partner_ids` of the `mail.mail` record.

So the old bug of "abandoned cart email is sent twice" reappered: the if condition fails to account for `use_default_to` being set, so the partner email is set explicitly on `email_to` AND referenced in `partner_ids`, which de-facto sends the email twice to the customer on the sales order.

## FIX:
We account for `use_default_to` in the if condition before adding the fallback.

How to reproduce:
1) Setup a database with demo data and website_sale 
2) Visit the shop as a visitor, add stuff to your cart 
3) Sign up for portal access and add new stuff to cart (will attribute SO to new portal account)
4) Wait for the abandoned cart email to trigger (can be forced by playing with `cart_recovery_email_sent`: false,`is_abandoned_cart`: true and triggering the CRON) -> mail is sent twice to the customer

Remarks:
- changed the unit test to actually capture the generated `mail.mail` and apply some asserts on it

OPW-6134731

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#261039

Steps to reproduce:
- Ensure:
  - Marc Demo is a “Project” admin
  - All projects have “allow_task_dependencies” set to false. This will remove the “Use Task Dependencies” group from Role / User, so the order of these steps is important
  - Add Role / User implies “Use Task Dependencies”
- Sign in as Marc Demo and attempt to create a new project from the “Product Launch Campaign” template

Description:
`_inverse_allow_task_dependencies()` uses `_check_project_group_with_field()` to determine if task dependency features should be enabled/disabled by modifying the `hidden` field on `mail.message.subtype` records (e.g. `mt_task_waiting`). This occurs whenever a project is created from templates. However write access to these records are restricted to admins, so we need elevated permissions when attempting to do so. Without `sudo`, access errors are thrown if non-admin users attempt to create projects under specific scenarios (i.e. when `_check_project_group_with_field()` adds or removes a group from the user base group).

The search within `_check_project_group_with_field()` also needs elevated permissions to prevent false negatives. Without `sudo`, this search is restricted by the user's record rules. If the user cannot see the specific projects where dependencies are active, the system may incorrectly assume that no projects use these dependencies, and will forcefully unlink the dependency group from `base.group_user`, breaking the feature globally for all users.

Applying `.sudo()` to the subtype modification and the project search ensures standard users can create projects from templates without crashing and prevents the accidental global removal of the dependency group.

opw-6099425

Forward-Port-Of: odoo/odoo#258996

Previously, computing warning_employee_rate fetched all analytic lines associated with projects.task_ids to check if any employee lacked a sale_order_line in project.sale.line.employee.map.

This approach had two major flaws:

	1- Iterating over all accessible tasks is highly inefficient for
	large projects, especially since many tasks do not even have
	associated analytic lines.

	2- Fetching analytic lines blindly by task_id could pull in lines
	linked to a completely different project_id adding performance issues.

**Solution**:
Since the compute method for the `project_id` field for the `account.analytic.line` model is making sure that the field `project_id` equal the project for the task, then we can remove the domain matching for the `task_id`.

We now can replace the `_read_group` with a simple SQL query, filtering out the unmapped projects directly.

The benchmark done below was on a database that had around 10M analytic lines, 2K `project_sale_line_employee_map` records and 1M tasks with the top 80 projects in terms of the number of `analytic.lines` + projects that had the most records in the `project_sale_line_employee_map`.
| Before | After |
| :--- | :--- |
| 33.0s | 170.0ms |

Forward-Port-Of: odoo/odoo#260935

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

# 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

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

#### 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

When generating a VAT return with an unclaimed tax amount carried to the
next month, the carryover reimbursement move amounts are computed with
an incorrect ratio.

Steps to reproduce:
- Create and post a bill in May containing a VAT amount.
- Create and post a bill in June containing a VAT amount.
- Create a VAT return for May to carry over the VAT amount to the next
  month.
- Create a VAT return for June, requesting the full VAT amount to be
  reimbursed.
- Validate and send the June VAT return.
- Check the generated reimbursement move

Issue: Line values does not correspond to anything real/tangible.  It
occurs because when computing the ratio for the move we check the last
tax report entry, where we find the amount of tax from the past months
and a line balancing the last month that should not be taken into
account.  The "Balance tax current account (receivable)" line from the
tax closing entry is mistakenly picked up as a tax carried forward line,
throwing off the amounts.

opw-5961836

Forward-Port-Of: odoo/enterprise#115451

During a previous fix (https://github.com/odoo/odoo/pull/206158), fallback values were added for an explicit `email_to` if the default email template for the abandonned cart was missing them.

But since (https://github.com/odoo/odoo/pull/172714), the template uses `use_default_to` == True, which will compute the default partner and add them to `partner_ids` of the `mail.mail` record.

So the old bug of "abandoned cart email is sent twice" reappered: the if condition fails to account for `use_default_to` being set, so the partner email is set explicitly on `email_to` AND referenced in `partner_ids`, which de-facto sends the email twice to the customer on the sales order.

## FIX:
We account for `use_default_to` in the if condition before adding the fallback.

How to reproduce:
1) Setup a database with demo data and website_sale 
2) Visit the shop as a visitor, add stuff to your cart 
3) Sign up for portal access and add new stuff to cart (will attribute SO to new portal account)
4) Wait for the abandoned cart email to trigger (can be forced by playing with `cart_recovery_email_sent`: false,`is_abandoned_cart`: true and triggering the CRON) -> mail is sent twice to the customer

Remarks:
- changed the unit test to actually capture the generated `mail.mail` and apply some asserts on it

OPW-6134731

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#261039

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

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

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

## 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

#### 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

# 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

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