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

Issue Before This Commit:
================================
Previously, the delivery carrier was only propagated between pickings when it
was set from the sale order. If the carrier was manually set on a picking
(e.g., during the packing step in a multi-step delivery flow), it was not
propagated to the consequent pickings, even when the stock rules had
`Propagation of carrier` enabled.

Steps to reproduce:
================================
1. Activate Multi-Step Routes and Delivery Methods.
2. Configure a 3-step delivery route in the warehouse and enable Propagate
   Carrier on all rules.
3. Create a sale order with a product but without setting a delivery carrier.
4. Confirm the sale order to generate picking.
5. On the first picking (i.e., pick), manually set a delivery carrier
   (e.g., Local Delivery) and validate.
6. On the next transfer (i.e., pack), observe that the delivery carrier is not
   propagated.

After this commit:
================================
The delivery carrier set on any picking is propagated to subsequent transfers
when the corresponding stock rule has `Propagation of carrier` enabled and no
carrier is already configured on the next picking.

This ensures consistent carrier propagation across all routing configurations
(all pull rules, all push rules, and mixed push/pull flows), even when the
carrier is configured at the picking level rather than on the sale order.
This behavior is required because, in many business scenarios, carrier selection
is managed by the logistics team rather than the sales team.

task-4454313

## Current behaviour:
When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order.

## Expected behaviour:
If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order.

## Steps to reproduce:
1. Validate a delivery order integrated with Starshipit.
2. Trigger a label generation failure (e.g., bad address).
3. Observe that the created Starshipit order is deleted.

## Cause of the issue:
The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order.

## Fix:
Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual.

## Additional note:
The _() wrapper in the error line was removed because
the Starshipit service has no env or language context.
Since translations cannot be resolved there, Odoo raised a warning.
Removing _() avoids this warning and keeps the error clean.

opw-5306979

### Steps to reproduce:
	- define a time-off type in hours
	- create working schedules :
		standard 40h (fixed hours)
		standard 20h (fixed hours)
		Flexible 40h (flex hours)
		Flexible 20h (flex hours)
	- create 2 employees: employee 1 with fixed hours ; employee 2 with flexible hours
	- create contract 1 Fix 100% (start in 01/01/2025 - standard 40h) and set it to running
	- create contract 2 Flex 100% (start in 01/01/2025 - Flexible 40h) and set it to running
	- register a 1st week t-o for each employee (ex: 08/03/2025-08/09/2025) ==> 40h and validate
	- register a 2nd week t-o for each employee (09/07/2025-09/13/2025) ==> 40h and validate
	- expire current contract (100%) for each employee and launch a new contract (50%) : 
		- Standard 20h (Fixed hours) for employee 1 ; 
		- Flexible 20h (flex hours) for employee 2 (start on 08/24/2025)
			==> set them to running

### Cause:
While we are recomputing the duration of the overlapping leaves
the resource_calendar for the employee is not yet changed so when
getting the work_intervals we are calculating it using the old hours_per_day.

Also since we are still writing to the contract and it is not yet
in running state so we won't be able to use _get_calendars_validity_within_period


### Fix:
We add the number of days and duration display to the compute queue
so it will be recomputed after we already change the employee's resource_calendar

opw-5010995

Situation
-----
When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054

because of the `m.location_id == move.location_final_id` part being false in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097

This is because, during the merge, `location_final_id` is not propagated to the new MO

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424

so when the new MO's `move_finished_id` gets computed

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822

it gets the MO's `location_final_id`

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202

which is false. This leads to to the move getting the warehouse's default stock location thanks to

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457

This is problematic for complex use cases with multi-locations and custom routes.

It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one.

Use case example
-----
<details>
<summary>Full use case</summary>

- Enable multi-step routes
- Create location "WH/Stock/L1"
- Create location "WH/Stock/L2"

- Create Operation Type "MO child"
	- Type of Operation: Manufacturing
	- Sequence Prefix: MOCHILD
	- Source Location: L1
	- Destination Location: L2
- Create Operation Type "Push Transfer"
	- Type of Operation: Internal Transfer
	- Sequence Prefix: L2L1
	- Source Location: L2
	- Destination Location: L1
- Create Route "MO child"
	- Create Rule "Manufacture"
		- Action: Manufacture
		- Operation Type: MO child
		- Source Location: False
		- Destination Location: Stock
- Create Route "2-step"
	- Warehouse: Main WH
	- Create Rule "L1 -> Virtual/Production"
		- Action: Pull from
		- Operation Type: MO child
		- Source Location: L1
		- Destination Location: Virtual/Production
	- Create Rule "Push: L2 -> L1"
		- Action: Push To
		- Operation Type: Push Transfer
		- Source Location: L2
		- Destination Location: L1
- Unarchive MTO
- Edit MTO route
	- Create Rule "L1 -> Virtual/production (MTO)"
		- Action: Pull
		- Operation Type: "My Company: Manufacturing"
		- Source Location: L1
		- Destination Location: Virtual/Production
		- Supply Method: Trigger another rule
- Create product "Main product"
- Create product "Child product"
	- Routes: "MO child" & MTO
- Create product "Material" (consumable)
- Create BOM
	- Product: "Main product"
	- Component: "Child product"
- Create BOM
	- Product: "Child product"
	- Component: "Material"
- Create MO for "Main product"
	- Misc/Component Location set to L1
- Duplicate the MO
- Merge child MOs & produce
- Validate merged MO transfer to L1
- Go back to one of the "Main product" MO

> Component quantity is 0
</details>

-----
Ticket:
opw-5144196

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

[FIX] mail: avoid error on service worker push subscription change

Sometimes, the `pushsubscriptionchange` event is called without an
`oldSubscription` defined, which can lead to an error occurring inside
the  service worker.

Steps to reproduce:

1. Enable notification in Odoo.
2. Reset the permission in the Chrome interface
3. Re-enable the permission inside the discuss systray by clicking on
the Odoobot message.
=> The pushsubscriptionchange is called without an oldSubscription


[FIX] mail: ir_cron_web_push_notification are now more robust

With a user having 5 registered devices for push notifications
if a browser registers with an endpoint that has a wrong domain
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX
the cron job cannot resolve the invalid domain of the endpoint and ends
up disabling it.


[FIX] mail: push_to_end_point method to support .invalid TLD

if a browser registers with an endpoint that has a TLD `.invalid`
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX

The TLD `.invalid`[1] is intended for use in online construction of
domain names that are sure to be invalid and which it is obvious at a
glance are invalid. The cron job cannot resolve the invalid domain of
the endpoint and ends up disabling it.

So we need to unregister a device with an endpoint with a `.invalid`
TLD.

[1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2


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

Forward-Port-Of: odoo/odoo#240502

The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing
the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese.

By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users.

Technical details:
- Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header
- Added Vietnamese translations for all tax records in the template
- Translations follow Vietnamese tax terminology conventions
- The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#236502

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