Description of the issue/feature this PR addresses:
This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745
In the above ticket, an employee Norbert Loibl had an accrual allocation
from Feb. 2023 to May 2024. Since then, all his allocations have been
regular allocations, so he is no longer accruing vacation days. But,
Norbert’s future leaves do not get counted against the “Days Available”
displayed on his Time Off Dashboard.

Current behavior before PR:
If an employee had an accrual allocation (of the relevant type, e.g. 
past vacation allocations won’t affect sick leave) at any point in 
time, their future leaves do not get counted against the “Days 
Available” on their Time Off Dashboard.

Desired behavior after PR is merged:
If an employee has an accrual allocation between today’s date and the
date of a future leave, that future leave does not get counted against 
the “Days Available” on their Time Off Dashboard. That way, we 
will count a leave against “Days Available” unless there is a 
possibility of accruing more days off before the leave.

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

Forward-Port-Of: odoo/odoo#241216
Forward-Port-Of: odoo/odoo#238977

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

**Current behavior before PR:**

- When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop.

- When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained

- When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location.

- When selecting an image with a caption and performing copy-paste, only the image was copied and pasted.

**Desired behavior after PR is merged:**

- An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes.

- Cutting an image that contains a caption now correctly removes both the image and its associated caption.

- The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication.

-  Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted.


task: 4914451

Forward-Port-Of: odoo/odoo#240788
Forward-Port-Of: odoo/odoo#217125

**Description of the issue/feature this PR addresses:**
----------------------------------------------
In version 19, when a message in the Chatter includes an attachment and an emoji
reaction is added, both elements appear visually too close to each other.
This overlap creates a cluttered look and reduces readability in the message view.

**Current behavior before PR:**
----------------------------------------------
- Emoji reactions and attachment previews are rendered too close together.
- Negative or insufficient top margin on the reactions container causes overlap.
- Visual inconsistency between text-only messages and messages with attachments.

**Desired behavior after PR is merged:**
----------------------------------------------
- Proper spacing between attachments and emoji reactions in the Chatter.
- Consistent, clean layout across all message types.
- Improved readability without affecting compactness for text-only messages.

Task-5259482

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

Forward-Port-Of: odoo/odoo#237943

Steps to reproduce:
1. Go to the theme tab and change the colors of the main preset.
2. Select any text in the footer.
3. Expand the toolbar and click the highlight option.

Issue:
The highlight selector still uses the default purple color instead of adapting to the updated theme preset. This happens because the text highlight color uses "--o-color-1", which does not update when the theme colors are modified.

Fix:
Used "var(--hb-cp-o-color-1)" as the default text highlight color instead of "--o-color-1", ensuring the highlight automatically adapts to theme changes.

Before This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="450" height="404" alt="image" src="https://github.com/user-attachments/assets/c92eed7e-1856-4e08-879a-a74e2506ab9c" /> | <img width="399" height="389" alt="image" src="https://github.com/user-attachments/assets/9a938e80-9e01-49fd-b6a1-cf9baaa64358" /> |


After This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="394" height="413" alt="image" src="https://github.com/user-attachments/assets/674958bc-7df7-44fa-97c0-5ae78608dc6a" /> | <img width="408" height="428" alt="image" src="https://github.com/user-attachments/assets/1d48ca49-7d18-4681-8443-b9887eef0dbf" /> |

task-5375414

Co-author: Alay Patel <alap@odoo.com>

Forward-Port-Of: odoo/odoo#238471

An error occurs when a user with `Employee Management` rights, but without any appraisal rights, tries to open an employee’s appraisals.

**Steps to Reproduce:**
1) Install Appraisals App.(with Demo).
2) Log in as admin, open Marc Demo in Settings > Users & Companies > Users,
   and set `Employees: Officer (Manage all employees)` under HR section.
3) Log in as Marc Demo and open any employee profile (e.g., Anita Oliver).
 4) Click on `Appraisals smart button`.

**Error:**
`IndexError: tuple index out of range`

**Root Cause:**
When a user has only employee management rights, `self.appraisal_ids` received in the method at [1] becomes an empty tuple. Accessing `self.appraisal_ids[0].id` therefore raises an `IndexError`.

**FIX:**
If no `appraisal_ids` are available, return the list view of appraisals, matching the behavior from previous versions.

[1]- https://github.com/odoo/enterprise/blob/3ee1df0b806f9c73d79b8b55fcc7d55b530d9e6b/hr_appraisal/models/hr_employee.py#L169-L180

sentry-7032734789

Forward-Port-Of: odoo/enterprise#99662

Issue
-----
After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step.

Steps to reproduce
-----
- Enable multi step routes
- Set WH to 3-step manufacturing
- Create a product
	- empty bom
	- MTO & manufacturing routes
	- 5 in stock
- Create a SO for the product
- Cancel the linked MO
- Open the delivery picking
- Click "Check Availability"

> The product is not getting reserved from stock

> The delivery picking is still "Waiting Another Operation"

Cause
-----
The problem happens in `action_cancel`

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1995

In 1-step case, `move.propagate_cancel` is false so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2017-L2021

where `move_dest_ids` is the move of the delivery picking.

This makes it so that, when we go to the delivery picking and do `action_assign` we go through the first condition while skipping the second of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1929-L1931

instead of going into the `else` part

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1947-L1949

In 3-step, when we `action_cancel`, `move.propagate_cancel` so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2009-L2014

which lacks the swap to MTS and unlink `move_dest_id` logic.

Solution
-----
We can re-use the logic of unlink and MTS swap to `move_dest_ids` that were not cancelled by

https://github.com/odoo/odoo/blob/0eb44aec8867e292f8258df02045efe7fbd3303f/addons/stock/models/stock_move.py#L2012

This also takes care of the problem of the status of the delivery picking being `waiting` instead of `confirmed` because it gets recomputed

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L754

and since it was set to MTS, it goes into the `else`part of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2202-L2216

-----
Ticket:
opw-5124380

Forward-Port-Of: odoo/odoo#241738
Forward-Port-Of: odoo/odoo#237890

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

### Issue:
Due to this issue, users can change the technical field `discount product` which cause inconsistency in discount description.

#### To reproduce:
1- Create a promotion called `AAA`:
  - Rules: If minimum 50.0 spent grant 1 point per order
  - Rewards: 10% discount per order in exchange of 1 point
 
2- Using debug mode, in promotion's reward view, change the `Description on order` to `AAA 10%`. Save the promotion and you can see the `Discount product`'s name is set to the same description.
3- Create another promotion called `BBB`:
  - Rules: If minimum 50.0 spent grant 1 point per order
  - Rewards: 10% discount per order in exchange of 1000 points.

4- In promotion reward's view change the `Discount product` to `AAA 10%` which is promotion `AAA`'s discount product.
5- Change the `Description on order` to `BBB 10%` and save.
6- You can see the name of `Discount product` is changed as well.
7- In promotion `AAA` and you can see the description and the name of `Discount product` mismatch.
8- Navigate to shop, and add a product to cart with a price of more than 50.
9. You can see after applying promotion `AAA` the description from promotion `BBB` is shown.

### Cause:
The technical field `Discount product` is never meant to be changed, and this field is introduced for reporting purposes and showing the discount applied in cart.

However, this field is added to view in #132857. This is done as a hack to find the `Discount product` created for the promotion, as a workaround for an accounting issue due to adding account to `Discount product`, and originally `discount_line_product_id` was not supposed to be shown or changed through form.

After discussion with PO, we decided this field should be removed from the view. Also removing this field will not undo the main fix of #132857, and that workaround was introduced only to find the `Discount product` for that specific client's use case.

However, in stable, it is kept for customization compatibility. It's set invisible in order to prevent the issue.

opw-5229633

Forward-Port-Of: odoo/odoo#240684

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

## Versions
17.0+

## Issue
Customers located in French territories (e.g. La Réunion) can't use Stripe Connect.

## Steps to reproduce
*Ensure Stripe payment provider is installed*
- From the Settings' app, access your company's data:
  - Change your company's country for "Réunion".
- Go to Payment Providers and open Stripe:
  - Try to enable Stripe via Stripe Connect;
  - A message tells you your country is not supported by Stripe.

## Cause
Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries).
This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow.

opw-5421185

Forward-Port-Of: odoo/odoo#241269

Description of the issue/feature this PR addresses:
This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745
In the above ticket, an employee Norbert Loibl had an accrual allocation
from Feb. 2023 to May 2024. Since then, all his allocations have been
regular allocations, so he is no longer accruing vacation days. But,
Norbert’s future leaves do not get counted against the “Days Available”
displayed on his Time Off Dashboard.

Current behavior before PR:
If an employee had an accrual allocation (of the relevant type, e.g. 
past vacation allocations won’t affect sick leave) at any point in 
time, their future leaves do not get counted against the “Days 
Available” on their Time Off Dashboard.

Desired behavior after PR is merged:
If an employee has an accrual allocation between today’s date and the
date of a future leave, that future leave does not get counted against 
the “Days Available” on their Time Off Dashboard. That way, we 
will count a leave against “Days Available” unless there is a 
possibility of accruing more days off before the leave.

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

Forward-Port-Of: odoo/odoo#241216
Forward-Port-Of: odoo/odoo#238977

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

**Description of the issue/feature this PR addresses:**
----------------------------------------------
In version 19, when a message in the Chatter includes an attachment and an emoji
reaction is added, both elements appear visually too close to each other.
This overlap creates a cluttered look and reduces readability in the message view.

**Current behavior before PR:**
----------------------------------------------
- Emoji reactions and attachment previews are rendered too close together.
- Negative or insufficient top margin on the reactions container causes overlap.
- Visual inconsistency between text-only messages and messages with attachments.

**Desired behavior after PR is merged:**
----------------------------------------------
- Proper spacing between attachments and emoji reactions in the Chatter.
- Consistent, clean layout across all message types.
- Improved readability without affecting compactness for text-only messages.

Task-5259482

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

Forward-Port-Of: odoo/odoo#237943

Steps to reproduce:
1. Go to the theme tab and change the colors of the main preset.
2. Select any text in the footer.
3. Expand the toolbar and click the highlight option.

Issue:
The highlight selector still uses the default purple color instead of adapting to the updated theme preset. This happens because the text highlight color uses "--o-color-1", which does not update when the theme colors are modified.

Fix:
Used "var(--hb-cp-o-color-1)" as the default text highlight color instead of "--o-color-1", ensuring the highlight automatically adapts to theme changes.

Before This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="450" height="404" alt="image" src="https://github.com/user-attachments/assets/c92eed7e-1856-4e08-879a-a74e2506ab9c" /> | <img width="399" height="389" alt="image" src="https://github.com/user-attachments/assets/9a938e80-9e01-49fd-b6a1-cf9baaa64358" /> |


After This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="394" height="413" alt="image" src="https://github.com/user-attachments/assets/674958bc-7df7-44fa-97c0-5ae78608dc6a" /> | <img width="408" height="428" alt="image" src="https://github.com/user-attachments/assets/1d48ca49-7d18-4681-8443-b9887eef0dbf" /> |

task-5375414

Co-author: Alay Patel <alap@odoo.com>

Forward-Port-Of: odoo/odoo#238471

Description of the issue/feature this PR addresses:
This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745
In the above ticket, an employee Norbert Loibl had an accrual allocation
from Feb. 2023 to May 2024. Since then, all his allocations have been
regular allocations, so he is no longer accruing vacation days. But,
Norbert’s future leaves do not get counted against the “Days Available”
displayed on his Time Off Dashboard.

Current behavior before PR:
If an employee had an accrual allocation (of the relevant type, e.g. 
past vacation allocations won’t affect sick leave) at any point in 
time, their future leaves do not get counted against the “Days 
Available” on their Time Off Dashboard.

Desired behavior after PR is merged:
If an employee has an accrual allocation between today’s date and the
date of a future leave, that future leave does not get counted against 
the “Days Available” on their Time Off Dashboard. That way, we 
will count a leave against “Days Available” unless there is a 
possibility of accruing more days off before the leave.

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

Forward-Port-Of: odoo/odoo#241216
Forward-Port-Of: odoo/odoo#238977

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

**Description of the issue/feature this PR addresses:**
----------------------------------------------
In version 19, when a message in the Chatter includes an attachment and an emoji
reaction is added, both elements appear visually too close to each other.
This overlap creates a cluttered look and reduces readability in the message view.

**Current behavior before PR:**
----------------------------------------------
- Emoji reactions and attachment previews are rendered too close together.
- Negative or insufficient top margin on the reactions container causes overlap.
- Visual inconsistency between text-only messages and messages with attachments.

**Desired behavior after PR is merged:**
----------------------------------------------
- Proper spacing between attachments and emoji reactions in the Chatter.
- Consistent, clean layout across all message types.
- Improved readability without affecting compactness for text-only messages.

Task-5259482

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

Forward-Port-Of: odoo/odoo#237943

Steps to reproduce:
1. Go to the theme tab and change the colors of the main preset.
2. Select any text in the footer.
3. Expand the toolbar and click the highlight option.

Issue:
The highlight selector still uses the default purple color instead of adapting to the updated theme preset. This happens because the text highlight color uses "--o-color-1", which does not update when the theme colors are modified.

Fix:
Used "var(--hb-cp-o-color-1)" as the default text highlight color instead of "--o-color-1", ensuring the highlight automatically adapts to theme changes.

Before This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="450" height="404" alt="image" src="https://github.com/user-attachments/assets/c92eed7e-1856-4e08-879a-a74e2506ab9c" /> | <img width="399" height="389" alt="image" src="https://github.com/user-attachments/assets/9a938e80-9e01-49fd-b6a1-cf9baaa64358" /> |


After This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="394" height="413" alt="image" src="https://github.com/user-attachments/assets/674958bc-7df7-44fa-97c0-5ae78608dc6a" /> | <img width="408" height="428" alt="image" src="https://github.com/user-attachments/assets/1d48ca49-7d18-4681-8443-b9887eef0dbf" /> |

task-5375414

Co-author: Alay Patel <alap@odoo.com>

Forward-Port-Of: odoo/odoo#238471

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

### Step to reproduce:
1. Create db in version 17.0 and create a many2one field
   with ``mail.push.device``
2. neturalize the db. All records of res.users will be vanish due to  ``TRUNCATE mail_partner_device CASCADE;``

### Issue: 
during neutralize if there is any custom/studio field many2one with ``mail.push.device`` even if the mail partner device
record won't used it in particular model still it will wipe out all the records of that model on neutrilizing
which can issue during testing on neutrlized db 

**To fix it :** 
 [here](https://github.com/odoo/odoo/pull/133560/files#diff-284b40b100919f9b1d4f7bee50740387fea5f11815210baa5f6de9cbf317ca6dR14) want to delete only partner device. So, adjusted query using ``DELETE FROM mail_push_device`` instead of truncate.  

below traceback will generate due to this during upgrade.
```
Traceback (most recent call last):
  File "/home/odoo/bin/misc/update_module_list.py", line 25, in <module>
    env["ir.module.module"].update_list()
  File "<decorator-gen-87>", line 2, in update_list
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 71, in check_and_log
    log_data = (method.__name__, self.sudo().mapped('display_name'), user.login, user.id, origin)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1188, in __get__
    raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: res.users(1,), User: 1)
[ERROR]::Error during the upgrade:
```


opw-5443072
upg-3712726

Forward-Port-Of: odoo/odoo#241535

## Versions
17.0+

## Issue
Customers located in French territories (e.g. La Réunion) can't use Stripe Connect.

## Steps to reproduce
*Ensure Stripe payment provider is installed*
- From the Settings' app, access your company's data:
  - Change your company's country for "Réunion".
- Go to Payment Providers and open Stripe:
  - Try to enable Stripe via Stripe Connect;
  - A message tells you your country is not supported by Stripe.

## Cause
Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries).
This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow.

opw-5421185

Forward-Port-Of: odoo/odoo#241269

This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested snippets.

**Accordion issues**
How to reproduce: drop two nested `s_accordion` snippets. Then:
1. Change the outer "Style" from "boxed" to "highlight active" -> both accordion change,
2. Change the outer "Round Corner" -> both accordion change,
3. Change the outer "Icon Position" ->  both accordion change.

**Blockquote issues**
How to reproduce: drop two nested `s_blockquote` snippets. Then:
1. Change the outer "Decoration" -> both blockquotes change,
2. Set the inner "Decoration" to "Icon" -> works only if the outer snippet has icon too,
3. Change the outer "Author Alignment" -> only the inner blockquote changes.

**Cause**
The above issues occur because certain `data-apply-to` and certain CSS selectors match all nested elements rather than restricting the scope only to the snippet being edited.

**Fix**
The relevant `data-apply-to` and CSS rules now use the child combinator `>` when needed.

task-5362171

When users would follow the following step as they are makeing a private task,  they would be hit by an incorrect access error.

Steps to reproduce:
1.Open the form view to create a new task.
2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task.
4.Create the private task.
5.An access rights error occurs, stating that the user does not have permission to create the record.

⚠️ Note:
This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs.

Root cause:
When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation.

This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users.

Fix (implemented):
Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing.
To address this, we now require at least one user to be assigned to a task when it is not attached to a project.  This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record


Versions : 17.0 -> master
Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr