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:

- Create a bom for a product with 2 component lines:
    - 1 x COMP1
    - 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis

### Cause of the issue:

Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.

opw-5243203

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

Forward-Port-Of: odoo/odoo#239654

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

In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order

Steps to reproduce:
-------------------
* Create a product with instantly generated variants
* Create a combo choice and add one of his variants
* Create a combo product and add the combo
* Open an store that sells this combo
* Select the combo and choose the product with variant and confirm the selection

Issue : On the left size in the order the variant name will not appear.

Observation:
------------
When it tries to construct the name of the product it need the attribute_value_ids:
https://github.com/odoo/odoo/blob/35c77b89e4c0db035ad25fef9a34be6ef74db7b5/addons/point_of_sale/static/src/utils.js#L36-L39
Since in our case the product is a variant "always" the attribute are not inside attribute_value_ids, it will not have them :
https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33

opw-5037355

Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company.

This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket.

Steps to reproduce the issue:
----------------------------
1. Install helpdesk module
2. Create a new company B
3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user
4. Select that new company created in step and go to helpdesk app.
5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team
6. log in as the user created in step 3
7. make usre the company selected is the one created in step 2
8. create a ticket in the helpdesk team created in step 5

Expected behavior:
-----------------
The ticket should be created without any issue.

Actual behavior:
---------------
An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one.

opw-5223717

Forward-Port-Of: odoo/enterprise#102910
Forward-Port-Of: odoo/enterprise#102859

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError.

This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets.

#### Benchmark

In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB.

<img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" />

<img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" />

Forward-Port-Of: odoo/enterprise#102364