### Issue:
- Sick leaves were calculated using the leave record dates, so leaves that started in one month and continued into another month were not counted correctly.
- The Basic salary rule was applied even when there were no `WORK100` work entries on the payslip.

### Fix:
- Updated the leave filtering logic to consider leaves whose `request_date_from` or `request_date_to` overlaps with the payslip period year, instead of relying solely on the leave start date.
- Adjusted the Basic salary computation to execute only when `WORK100` exists in `worked_days_line_ids`, preventing calculation when no effective worked entries are present.

### Impact:
- Ensures sick leave days are correctly accounted for in the relevant payslip period, even when the leave spans across months.
- Prevents incorrect Basic salary computation on payslips with no `WORK100` work entries, resulting in accurate payroll calculations.

---

task-5462380

Forward-Port-Of: odoo/enterprise#109892
Forward-Port-Of: odoo/enterprise#104401

### Issue:
When in the Gantt view of service projects, grouping by project results in a traceback.

### Steps to reproduce:
- Create another field service project 
- Create a task in the new project and add start and end dates
- Go to Field service > my tasks > gantt view > group by project 
- Error with traceback `time data 'today' does not match format '%Y-%m-%d %H:%M:%S'`

### Cause:
This [commit](https://github.com/odoo/odoo/commit/d1ea43f6721116914762ea323d8a5987f043e87f) added the possibility to use dynamic dates in domains. Then all domains were changed in 42b1fca8e127926a06f503d79c8baeddf7d5ae82

But `_expand_domain_dates()` is trying to parse the dates as if they were written in ISO format:

https://github.com/odoo/enterprise/blob/be853cc1ee544dda580960d94417cfdff2c8a7db/project_enterprise/models/project_task.py#L626

### Solution:
We use the method `parse_date()`, which was added with dynamic dates, to parse them.

opw-5955317

Forward-Port-Of: odoo/enterprise#109236

## [FIX] planning: make sure allocated_percentage is defined in the view

Before this commit, since we remove the allocated percentage field from
the form view, the framework js does not know that field has a default
value and so it will set 0 by default for the float field and give it as
parameter when it will request an onchange when the user wants to create
a new shift.

This commit makes sure the field is inside the form view to be sure the
default value is taken into account to correctly compute the
allocated_hours.

## [FIX] planning: make sure we compare apples with apples

Before this commit, the copy previous week action in planning.slot could
crash because values for new shifts could contain Commands in
`resource_ids` field.

This commit makes sure we convert those commands into resource ids to be
able to compare those ids with the ones on the shift processed.

## [FIX] planning_field_service: display map view in mobile in My Map

Before this commit, the `My Map` action displays the calendar view in
mobile instead of the map view.

This commit makes sure we first display the map view in any device when
`My Map` action is loaded.

## [FIX] planning_field_service: hide field service buttons when slot not published

Before this commit, some buttons in planning.slot were visible even if
the intervention is not published or in progress.

This commit makes sure the buttons are visible when the state of the
intervention is published or in progress depending on what is the
purpose of the button.

## [FIX] planning_field_service: open full form view in calendar

This commit makes sure the form view is fully opened in the calendar
view of planning.slot instead of opening it inside a modal.

## [FIX] web_gantt: undo the rechescule of shifts and keep resources set

Before this commit, when the user reschedules a shift by drag and
dropping a pill in the gantt view and the group by is by Resources, if
the shift was assigned to more than one resource and the user undo his
action, the shift will be assigned to only the resource where the pill
was before the drag and drop instead of keeping its initial resources
set.

This commit makes sure the resources which were assigned to shift are
correctly set once the user undo the reschedule made.

## [FIX] planning_holidays: correctly compute the search domain for is_absent

Before this commit, the `employees on time off` filter does not return
the shifts with at least one human resource off due to wrong calculation
made in the search method of `is_absent` field defined in
`planning.slot` model.

This commit fixes the issue to correctly show the shifts with at least
one human resource off in the period of the shift.

## [FIX] planning_field_service_{sale_timesheet,worksheet}: display photos before materials

This commit makes sure the Photos button is before the one to add
materials in the intervention.

## [FIX] planning: display icon instead of label in calendar view

This commit reviews the popover in the calendar view of planning.slot to
replace the label by the icon to let more space for the value of each
fields displayed in that popover.
It also display in week by default the calendar view of planning slot in
My planning menu

## [FIX] planning: don't send re-assign email when one more resource is assigned

Before this commit, when the user edits a shift to add an additional
resource to the shift, the resource initially assigned to the shift will
receive a re-assign email even if he is still assigned to the shift.

This commit makes sure the email is sent only when the resource is no
longer assigned to the shift.

## [FIX] planning_field_service: add navigation map button to popovers and some fixes

This commit mainly adds a button to easily redirect the user to google
map with the customer address.

## [FIX] planning: don't show seconds in allocated_hours field

Before this commit, due to a rework of duration format, the allocated
hours now displays the seconds which is not really needed and take more
space than expected.

This commit makes sure we don't display the seconds in the allocated
hours field of planning.slot since that information is not really
useful.

## [FIX] planning{_field_service}: simplify display_name and conflicts warning

This commit simplifies the conflict warning in the form to have a
minimal warning message. The display name has been reviewed to only
display partner_id and role_id if partner_id otherwise project_id and
role_id will be displayed.

## [FIX] planning: don't include material resources when a human resource is set

This commit removes the material resources in the compute allocated
hours when there is at least one human resource set with it since we
could assume the material resources will just be used by the human
resource(s) assigned to the shift.

## [FIX] planning_field_service: fix geolocation when sign_in/complete intervention

Before this commit, the geolocation feature does not work because it was
only done in sign in button in calendar popover of planning.slot but the
feature is also needed when the user clicks on sign in and complete
buttons in the other views of planning.slot.

This commit makes sure the geolocation feature works in any view where
the sign in and complete buttons are currently displayed.

## [FIX] planning_field_service: add subtypes

## [FIX] planning: don't generate shifts in multi create when no resource available

Before this commit, when the user wants to create multiple shifts for a
certain resource in the gantt to cover a whole week (weekend included),
the shifts in the weekend will be generated as open shift since the
resource does not work during the weekend. Actually, the shifts should
not be generated in non working day for the resource.

This commit makes sure the shifts are not generated in non working day
of a resource selected.

## [FIX] planning_field_service: facilitate the work of planning manager

Before this commit, the planning manager cannot sign in for one of his
workers in the case, one worker forgot to do it and the intervention is
in the past. Hide price feature does not work correctly because the
check to know if the feature is enabled or not does not take the right
setting (wrong module because the feature has been moved before the
merging the main task).

This commit make sure the sign in button is available even if the
intervention is in the past. Some wordings have been reviewed and fix
typo to correctly check if hide price is enabled or not in the setting
of planning.
This commit also hides some fields for planning user when field service
is enabled in planning to only show the most important information for
the workers.

## [FIX] planning_field_service: add Today filter by default in My Map

## [FIX] planning_field_service: sign-in should recompute end date when needed

Before this commit, since the user can sign in when the shift is in the
past, we need to recompute the end_datetime to make sure the
end_datetime set is not before the start_datetime.

This commit recomputes the end_datetime when the shift is in the past
and the user clicks on sign in since the button will update the start
datetime to current time.

## [FIX] planning{_field_service_worksheet}: fix mobile form view in gantt

Before this commit, the Photos button displayed in the form view in
gantt does not have the same width than the other buttons in the form in
mobile. Moreover, a margin left is added on the first button in the form
view in gantt but in mobile that button is no longer aligned with the
other ones displayed.

This commit fixes those issues to make sure the buttons in the form view
displayed in the gantt view have the same width and the same alignment.

## [FIX] planning_field_service: fix break_time compute

Before this commit, the allocated hours field contained the sum of the
working hours of the human resources when there is at least one human
resource and so the working hours of the material resource assigned on
the intervention is not taken into account. Also, the compute of break
time field does not correctly compute it when there is more than one
resource.

This commit adapts the compute of break time according to the changes
made in the compute of allocated hours.

## [FIX] planning_field_service: hide Sign in button when no customer set

## [FIX] planning_field_service: fix SOL flow when confirming shift and portal

Before this commit, the portal views were not correctly supported the
portal user (missing sudo to find interventions completed and related to
the user which is the customer). A route is not adapted to the new route
in field service feature of helpdesk.

This commit fixes the access error in the portal to make sure the portal
user can access to intervention made for him.

## [FIX] planning_field_service_sale_timesheet: avoid copying SO and SOL

Before this commit, when field service and Billing features are
installed in planning and the user duplicates an existing intervention,
the SO and SOL fields are also copied and so the new materials added to
the new intervention will be added inside the same Sale Orders then the
one copied which is not really expected.

This commit avoid copying SO and SOL when duplicating an intervention
when field service is enabled in planning.

## [FIX] planning_field_service_sale_timesheet: rename label of back button in product

## [FIX] project_timesheet_forecast: fix compute effective hours

Before this commit, when field service and Billing features are enabled
in planning and the user completes an intervention, the allocated hours
and the break time are recomputed when the timesheets are generated for
the intervention, because of the hours recorded could be wrong in the
case the intervention finished after the working schedule of the workers
assigned. The issue is because when a timesheet is created, the
timesheet_ids field is recomputed and recompute effective hours and
allocated hours with other fields. Moreover, timesheet_ids is not stored
and is inside the compute of effective hours and that field is stored
which is not a good practise since the compute of effective hours will
do many write on db since timesheet_ids field will be recomputed each
time we need to read that field.

This commit reviews the compute of effective_hours to no longer depends
on timesheet_ids and makes sure the effective_hours field in
planning.slot are recomputed for the right slots when the employee_id,
date, task_id, project_id and unit_amount field are updated (or when the
timesheet is created). By doing that, that compute will only be computed
when needed.

## [FIX] planning_field_service: add some fields in calendar portal, and some more fixes

This commit adds the new fields added by field service in the planning
portal made for employees without any users to access in the backend.

task-5921961
task-5994180

Forward-Port-Of: odoo/enterprise#109332

Steps:
- Take any structure and ensure the YTD option is turned off in that structure.
- Go to Payroll > Payslips and create a few payslips with that structure. Confirm them.
- Now, enable the YTD setting in that structure.
- Open those confirmed payslips and check the YTD amount. It's not accurate.

Issue:
- When YTD tracking was enabled after confirming some payslips, the worked days
  section showed zero in the YTD column.
- This caused confusion because:
   - The salary line YTD  showed the current payslip’s amount,
   - The worked days YTD showed 0. Both should accurate.
- YTD values were only computed if ytd_computation was enabled during
  compute_sheet method.
- As confirmed payslips aren’t recomputed, worked days showed 00 YTD amount,
  when the setting was turned on later.

Fix:
- Removed conditional checks on 'ytd_computation' from the YTD calculation logic.
- YTD values are now always computed and available on payslips and worked days.
- The 'ytd_computation' checkbox  in structure is retained only for visibility toggling.
- e.g. showing/hiding YTD columns in payslips, reports or UI.

Task - 4790749

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

Forward-Port-Of: odoo/enterprise#109741
Forward-Port-Of: odoo/enterprise#105969

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.

Forward-Port-Of: odoo/enterprise#109812
Forward-Port-Of: odoo/enterprise#105521

*: {quality_,}mrp_workorder, quality_mrp_workorder_worksheet

### Steps to reproduce:

- Enable debug mode (to trigger a traceback rather than a silent error)
- In the settings, enable `Work Orders`
- Create an MO for a product without a BoM
- Add an operation to be performed in a workcenter
- Confirm the MO and open the Shop Floor
- Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display
- Click on `Add component` and add any valid component via the catalog

#### > Traceback: `OwlError: Got duplicate key in t-foreach`

### Cause of the issue:

The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72

Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice:
https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188

However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47

Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected.

In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error.

Community: https://github.com/odoo/odoo/pull/250966

opw-5417887

Forward-Port-Of: odoo/enterprise#106200