## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

### Issue:
Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong.

### Steps to reproduce:
- Have an employee with a calendar in "Europe/Brussels" and working from 8 to 17
- In planning add a line for this employee
- Display the gantt view on a day
- Create a shift for this employee from 8 to 17
- In the "Total" row, the first hour is not counted

### Cause:
To compute the values displayed in the Total row, we take the intersection of the shift and the working hours from the calendar. ([src](https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L318)) But the working hours from the calendar are given in UTC for this computation (without conversion), this result in a discrepancy between the actual hours of the calendar (with timezone conversion) and the one given to compute the total row.

### Solution:
`resource_work_intervals()` returns the work intervals with the calendar hours and the resource timezone.

In our case, only the hours are interesting (the previous code replaced the timezone by UTC). We need to convert them from the calendar timezone to UTC. So the first thing to do is remove the timezone from `resource_work_interval` then we localize it in the calendar timezone and to finish we convert it to UTC.

opw-5564749

In the `industry_fsm_report` and `quality_control_worksheet` modules, worksheet fields created during onboarding was moved from XML to Python (https://github.com/odoo/enterprise/commit/d619aa4d0d042be3f899b777081b7fb90f851c84). They were noupdate=1 before moving to Python ([quality_control_worksheet](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/quality_control_worksheet/data/quality_worksheet_demo.xml#L3), [industry_fsm_report](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/industry_fsm_report/data/fsm_report_demo.xml#L3)).

The issue is without this patch, the dbs which loaded those fields in version `19.0` will have referencing xmlid because of this PR #84602, with noupdate=0. On the other side as they do not have record in xml files, during the upgrade to > 19.0 it will introduce an issue like this:

```
odoo.upgrade.util.exceptions.UpgradeError: 💥 It looks like you forgot to call `util.remove_field` on the following fields: x_project_task_worksheet_template_2.x_worker_signature
2026-02-15 20:17:38,149 23 INFO db_3904048 odoo.service.server: Initiating shutdown
```

tbg-2468

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record is not a field service task.
* Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 
[2]
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related community PR: https://github.com/odoo/odoo/pull/241446

opw-5215989

Forward-Port-Of: odoo/enterprise#107716
Forward-Port-Of: odoo/enterprise#103487

Steps to reproduce
------------------
1. Install `pos_settle_due`
2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc).
3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0
4. Select the invoice(s)
5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom.

-> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method.

Why the issue
-------------
If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created.

That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions.

After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places:
1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation.
2. On the products screen, when using fast payment, that is fast validation.

For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation.

However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation.

The fix
-------
Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation.

Notes
-----
- We keep the methods in `payment_screen` for backward compatibility, they will be removed in master.
- We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so  it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`.

opw-5488587