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

****Behavior:****
**Current:**
In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user.

**Expected:**
The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list.

**Steps to reproduce:**
- Be in a multicompany environment: company A and B
- Create User with access to both but only one employee record for company A
- Switch to company B
- Create 2 services product, both creating a task in the same project.
- Activate Billable Rate Indicators in the settings
- Create a quote with both services and confirm
- Go to the related project, and in the Invoicing tab, link employee from company A to SOL2
- As the user, check both companies but set company B as current active
- Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured.

opw-5159195

Forward-Port-Of: odoo/odoo#234200

**Description of the issue this PR addresses:**
Ensure the `Permission Needed` label in the device selector on the discuss 
public page displays correctly and remains properly aligned when device
permissions are not granted.

**Current behavior before PR:**
- Since this [PR](https://github.com/odoo/odoo/pull/247838), the label could appear misaligned or overflow the button 
on smaller screens, causing UI inconsistencies on both desktop and mobile.

**Desired behavior after PR is merged:**
- The label stays properly aligned and adapts correctly to the available space, 
preventing UI glitches across screen sizes.

task-[6007860](https://www.odoo.com/odoo/project/1519/tasks/6007860)

Before [Larger and Smaller Devices]: 
<img width="639" height="49" alt="image" src="https://github.com/user-attachments/assets/1cd1e240-0f40-42f9-bf93-823add81878f" /> 
<img width="343" height="39" alt="image" src="https://github.com/user-attachments/assets/a7a0f920-39e3-4bb3-a647-461c94cab395" />

After [Larger and Smaller Devices]: 
<img width="638" height="47" alt="image" src="https://github.com/user-attachments/assets/16aa419b-2190-4fd1-a459-8a376d90c349" />
<img width="425" height="41" alt="image" src="https://github.com/user-attachments/assets/fb245378-c04b-4dd8-8c5b-39ad4adefadf" />

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

# How to reproduce
- Use a browser extension to manage your browser's timezone
- Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe)
- Go to the form view of an opportunity
- Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity)
- In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00)
- Go back to the opportunity for view

# The problem
The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11

# Why
The calendar view uses the browser's timezone to manage the dates. The smart button does not.

It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly.

The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences.

opw-5898520

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

Forward-Port-Of: odoo/odoo#251840
Forward-Port-Of: odoo/odoo#247984

__
Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 
__
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

Nothing happens

When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546

The company isn't taken into account in the domain, applying the holiday for every company.
 __
opw-5222883

Forward-Port-Of: odoo/odoo#248725
Forward-Port-Of: odoo/odoo#246994

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


opw-4879481

Forward-Port-Of: odoo/odoo#252285
Forward-Port-Of: odoo/odoo#245741

### 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#109706
Forward-Port-Of: odoo/enterprise#105521

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

**Issue**:
Billing a PO containing kit with several components can lead to incorrect
valuation of its components

**Steps to reproduce**:
- Create a kit product (by creating a BOM with 2 components) with AVCO valuation
- Create a PO for 1 unit at unit price 10
- Confirm PO and validate the receipt
- Go to the BOM of the kit product and check BOM overview
-> The cost of the two components are 5, which is correct
- Go to Accounting > Vendors > Bill
- Create a new bill by indicating the PO in "Auto-Complete" field and validate
- Go back to the BOM of the kit product and check BOM overview
-> The cost of the two components are 10, which is correct

This also occurs with FIFO valuation

**Cause**:
While computing the value of the move:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314
It checks the value of the Bill:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358
Which relies directly on the AML price of the kit:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170
This ignores the `cost_share` of each BOM component. As a result,
each component receives the full kit value instead of its proportional
share

This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393

**Aditionnal note**
The computation of the quantity is also incorrect:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169
since it assumes the quantity of component of the kit is the same than the quantity of the kit itself,
which is not true in the general case.

opw-5924940

Forward-Port-Of: odoo/odoo#249264

`l10n_mx_edi_pos` is now populating `pos_order_ids` [1]. l10n_mx_edi_pos is designed to send POS data into MX EDI without giving accounting users direct access to pos.order. So, we should consider that in this module we won't have access to:

- `pos_order_ids` m2m on `l10n_mx_edi.document` (caused problems before [2])
- `pos_order_ids` o2m on `account.move`
- `pos.order` model

We add a minimal `sudo()` in
`_create_update_invoice_document_from_invoice` to be able to read from the `pos_order_ids` field on `account.move`:

```
  File "/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 54, in _create_update_invoice_document_from_invoice
    if invoice.pos_order_ids:
       ^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 967, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 45, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields.py", line 1743, in __get__
    recs._fetch_field(self)
  File "/c19-1/odoo/orm/models.py", line 3015, in _fetch_field
    self.fetch(fnames)
  File "/c19-1/odoo/orm/models.py", line 3055, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/models.py", line 3193, in _fetch_query
    field.read(fetched)
  File "/c19-1/odoo/orm/fields_relational.py", line 985, in read
    raise AccessError(records.env._("Failed to read field %s", self) + '\n' + str(e)) from e
odoo.exceptions.AccessError: Failed to read field account.move.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

Afterwards `_create_update_document` in `l10n_mx_edi` will create or write this `pos_order_ids` value on the document without `sudo()`:

```
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 56, in _create_update_invoice_document_from_invoice
    return super()._create_update_invoice_document_from_invoice(invoice, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1969, in _create_update_invoice_document_from_invoice
    document = remaining_documents._create_update_document(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1936, in _create_update_document
    result_document = self.create({
                      ^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/decorators.py", line 365, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4021, in create
    records = self._create(data_list)
              ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4253, in _create
    field.create([
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 760, in create
    self.write_batch(record_values, True)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 1559, in write_real
    raise AccessError(model.env._("Failed to write field %s", self) + "\n" + str(e))
odoo.exceptions.AccessError: Failed to write field l10n_mx_edi.document.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

We therefore take out `pos_order_ids` in an override and write it ourselves with another minimal `sudo()`.

[1] https://github.com/odoo/enterprise/pull/97060
[2] https://github.com/odoo/enterprise/pull/99590

opw-6000974

**Steps to reproduce:**
1. Configure Working Hours: Set up a night-shift schedule that splits at midnight (Local Time):
- Thursday: 20:00 to 24:00
- Friday: 00:00 to 04:00
2. Assign the above calendar to an employee.
3. Set the Employee’s Timezone to Asia/Kolkata (UTC+5:30).
4. Assign an active Overtime Ruleset to the employee.
5. When the attendance calendar is in Europe/Brussels TZ 
- Check-in: Jan 15, 15:30 CET
- Check-out: Jan 15, 23:30 CET

Expected Behavior: Worked Hours = 8.0, Overtime (Extra Hours) = 0.0 
Actual Behavior (Bug): Worked Hours = 8.0, Overtime = 4.0

**Bug Cause:**
1. The _update_overtime function normalized the Ruleset version periods using time.min for both the start and end of the day.
This forced the validity period of the rules to end exactly at 00:00:00 UTC on the final day.
2. The overtime recalculation logic failed to delete existing overtime records because the search domain was incorrectly computed.
Specifically, using relativedelta(SU) and relativedelta(MO(-1)) without the weekday= keyword argument did not shift the dates to the week boundaries.
This resulted in an empty or incorrect deletion range, leading to duplicated overtime hours as new records were layered on top of un-removed old ones.

**Solution:**
1. Modified the version_periods_by_employee mapping to use time.max (23:59:59) for the end of the version period.
This ensures that the ruleset remains active through the entire final calendar day in UTC, allowing shifts that cross the midnight boundary to be fully captured.
2. Corrected the date range logic by explicitly passing the weekday argument to relativedelta.
This ensures the domain correctly targets the full week window - from the preceding Monday to the following Sunday, ensuring all relevant stale overtime lines are purged before recalculation.
3. Updated Manual Edit Handling: Refined the logic to detect days with manual overrides or "To Approve" statuses before unlinking. If an attendance change triggers a recalculation on such a day, the system now replaces the manual entry with the mathematically correct value but flags the new record with a to_approve status for manager review.
4. Adjusted the expected overtime in test_weekly_overtime to 18.0 to correctly reflect the cumulative calculation of daily overtime (2h/day) plus the weekly overtime threshold reached on Friday.

Task: 5710273

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

**Description of the issue this PR addresses:**
----------------------------------------------
Some livechat demo sessions included feedback/ratings but were still
displayed as active conversations in the info side panel. This created
inconsistent demo data where closed conversations appeared with options
meant for ongoing chats (e.g., status shown instead of outcome).

**Current behavior before PR:**
----------------------------------------------
- Certain demo livechat sessions had ratings applied but no explicit livechat_end_dt set.
- As a result, the info side panel treated them as ongoing conversations.
- This caused mismatched UI information for demo data.

**Desired behavior after PR is merged:**
----------------------------------------------
- Demo livechat sessions that received feedback are explicitly marked as ended using livechat_end_dt.
- The info side panel correctly reflects closed conversations with coherent outcome information.

Task-5412081

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

Forward-Port-Of: odoo/odoo#250001

## Description

There was a desync issue with popup states between normal mode and edit mode. That caused:
- Hidden popups contributed extra dropzones during drag-and-drop
- Hidden popups lost `d-none` class after dropping unrelated snippets

## How to reproduce

### Bug 1: extra dropzones from hidden popup desync
1. Enter website edit mode.
2. Drop popup in the page
3. Drag another snippet as you were adding it to the page
4. An additional dropzone appears below the invisible popup snippet

### Bug 2: hidden popup loses `d-none` class
1. Enter edit mode.
2. Drop a popup.
3. Close it so `.s_popup` gets `d-none`.
4. Drop any other snippet on the page arbitrarily.
5. Popup loses `d-none` class.

## Expected behavior after fix

- Popup hidden/shown state remains stable across editor refreshes and
snippet drops.
- Drag-and-drop no longer creates extra dropzones from hidden popups.

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

Forward-Port-Of: odoo/odoo#251517
Forward-Port-Of: odoo/odoo#250625

****Behavior:****
**Current:**
In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user.

**Expected:**
The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list.

**Steps to reproduce:**
- Be in a multicompany environment: company A and B
- Create User with access to both but only one employee record for company A
- Switch to company B
- Create 2 services product, both creating a task in the same project.
- Activate Billable Rate Indicators in the settings
- Create a quote with both services and confirm
- Go to the related project, and in the Invoicing tab, link employee from company A to SOL2
- As the user, check both companies but set company B as current active
- Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured.

opw-5159195

Forward-Port-Of: odoo/odoo#234200

**Steps to reproduce:
1. Create DE company (EUR currency)
2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month)
3. Install l10n_de_reports
4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank]
5. Create USD invoice for XX/02/26 and confirm it
6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment)
7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data

**Description of issue:
The currency exchange rate difference entries in the exported file are shown as 0

**Expected behavior:
The actual currency exchange difference values should be displayed

**Why this happens?
The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export.

**The fix:
Updated the logic to use the line balance when the entry is identified as a currency exchange difference.

opw-5358954

Forward-Port-Of: odoo/enterprise#107268

Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433

Forward-Port-Of: odoo/enterprise#107760

### 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 to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#109638
Forward-Port-Of: odoo/enterprise#102126

## Description of the issue/feature this PR addresses:
If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)
![image](https://github.com/user-attachments/assets/7747b0ee-fb36-43d1-bfde-5f3ad29ce77d)

First column: Client ref
Second column: committment date
Third column: Customer

## Current behavior before PR:

When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. 
The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d  format .
This is an error because that column does not contain a date .
The reason is that check_patterns when convert the pattern to reg ex using
`def to_re(pattern):`
on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex .


## Desired behavior after PR is merged:
No error should appear and the correct date format from the right date column should be guessed 



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

Forward-Port-Of: odoo/odoo#196477

Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433

Forward-Port-Of: odoo/enterprise#107760

Problem: When computing the `shipping_weight` for pickings with packages,
we use package weights. If a picking is passed via the context, the
package weight is computed using the contained product weights. Otherwise,
it just uses the `package.package_type_id.base_weight` or 0.

This issue occurs when computing the `shipping_weight` for multiple
pickings at one time. Odoo prefetches the packages and their weights are
computed using the context of the first picking. If a package does not
belong to the first picking, their weight is not computed using its
`stock.move.line` product weights and the incorrect value is cached. When
the loop reaches the next picking, it uses the incorrect weight that was cached.

Purpose: Add `@api.depends_context('picking_id')` to `_compute_weight` so that
package weights are cached per picking.

I have updated this assert
https://github.com/odoo/odoo/blob/338fc201cc0ed0f2fd8349fab4f538817e69a295/addons/stock_delivery/tests/test_packing_delivery.py#L316-L317
to explicitly pass the `picking_id` in the context when checking the cached package weights.

Steps to Reproduce on Runbot:
Navigate to Inventory > Configuration > Settings and enable Packages.
Create a new storable product with a weight of 1 kg and add 2 units on-hand.
Create a delivery for 1 unit of our newly created product, mark as todo and put in a pack.
Create a second delivery for 1 unit of our newly created product, mark as todo, and put in a pack.
Observe on the second delivery the weight for shipping is 1 kg.
Navigate to the list view of deliveries and add the weight for shipping field to the view.
Search for both deliveries we created and observe the first one has a weight for shipping of 1 kg,
but the second one has a weight for shipping of 0 kg.

opw-5902814