…n batch billed on ordered qty

**Problem:**
When the picking of a purchase order (of a product billed on ordered quantity) is split into different
moves and put in a batch, at batch validation, svls are created with the wrong values.

 **Steps to reproduce:**
    - enable "Batch, Wave & Cluster Transfers" settings
    - create a storable product with a standard price of 1
    - set the category as avco
    - in the Purchase tab select the control policy as
    "on ordered quantities"
    - create and confirm a purchase order for 50 of this product
    - on the Receipt, change the quantity to 20 and split the
    picking
    - go back the the PO and create and confirm a bill for
    the full amount
    - click on the receipt smart button
    - select the two pickings and then the 'Action' button
    - select add to batch
    - check 'new batch transfer' and confirm
    - open the batch and validate it
    - open stock valuation
    
**Current behavior:**
    the newly created svls have total values of
    50 and 50.10

**Expected behavior:**
    it should be 20 and 30
    
**Cause of the issue:**
When the batch is validated, _action_done is called 
on the two stock moves.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/stock/models/stock_picking.py#L1258
In the stock_account override: 
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 50.
- then product_price_update_before_done is called before creating
the svls.

Inside product_price_update_before_done we call _get_price_unit.
In the purchase_stock override of _get_price_unit : 
- because the super method of action_done was already called, 
qty_received of the purchase order line is 50, so _get_qty_received_without_self
will return 30. 
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L50
So received_qty is 30 and later remaining_qty will be 20
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later 
remaining_value will be 50
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L63
Therefore price_unit will be 2.5 (50/20) instead of 1 

**fix**
We do not take into account the move(s) of the 
same batch in the remaining value (because svls are not created yet)
so we should not  take them into account in the remaining quantity.

opw-5179581

Forward-Port-Of: odoo/odoo#238222
Forward-Port-Of: odoo/odoo#235601

This error occurs when the user try to send invoice.

Steps to reproduce:
- Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company
- SetUp `Taiwan Electronic Invoicing` in settings
- Create a New Customer with `Email` and `Tax ID` (eg: 12345678) - and no `phone` number.
- Create New Invoice with created Customer > Confirm > Send > `Send to Ecpay` > Generate

Traceback:
`AttributeError: 'res.partner' object has no attribute 'mobile'`

This issue occurs at [1] because when the `phone` field is not set, the system tries to fall back to the `mobile` field. However, the `mobile` field was removed from `res.partner` (see related reference), and it was reintroduced in the referenced [commit].

This commit cleans up the logic to avoid referencing a non-existent field.

[1]: https://github.com/odoo/odoo/blob/f1deed16e2355a74fea522439826625535eb7052/addons/l10n_tw_edi_ecpay/models/account_move.py#L677-L678

reference- https://github.com/odoo/odoo/pull/189739

[commit]: https://github.com/odoo/odoo/pull/236938/commits/c7404dff58f232103af4271a445d3841a82be8a3

sentry-7086174794

Forward-Port-Of: odoo/odoo#238657

Problem:
When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs.

Cause:
After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247
and then call `getFonts()`, which internally uses
`this.dependencies.split.splitAroundUntil()`.

If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws:
`The offset x is larger than the node's length (y).`

Solution:
After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid.

Steps to reproduce:
It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`.
A test case replicating the situation can be based on the original failing template in the customer’s database.

opw-4953943

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

Forward-Port-Of: odoo/odoo#238450
Forward-Port-Of: odoo/odoo#234328

Currently, an error occurs when user marks multiple Manufacturing Orders as Done.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1XfkMB001rMiyulRGrP4dlJFDYByo_5Bv/view?usp=drive_link)):**
 - Install the `mrp` module.
 - Go to `Settings` and enable `Units of Measure & Packagings`.
 - Go to `Products and `create two products` with different `units of measure`.
 - Go to `Manufacturing Orders`, create a manufacturing order by `adding one of the products`, and then `create work order` in the Work Orders section and `confirm` it.
 - Create another `manufacturing order` with the `same quantity` for the second product and add a `Work Order` for it as well and `confirm` it.
 - Go to the `list view`, select `both orders`, and click `Mark as Done` from the `Actions` menu.

**Error:**
```
ValueError: ValueError('Expected singleton: uom.uom(4, 6)') while evaluating
"if records:\n                res = records.filtered(lambda mo: mo.state in {'confirmed', 'to_close', 'progress'}).button_mark_done()\n                if res is not True:\n                    action = res"
ValueError: Expected singleton: uom.uom(4, 6)
```

After [this commit], which improves the performance of button_finish, when a user marks multiple orders as done with the same quantity but different uom , it creates all_vals_dict based on the vals[1] data as the key and the work order as the value[2]. Then it  stores two or more work orders with different UoMs under the same vals key. When attempting to write multiple work orders[3], the precision rounding is calculated, which raises the error[4] due to multiple UoMs.

The commit ensures that when writing records, precision_rounding is calculated separately for each Work Order's UoM.

[this commit]: https://github.com/odoo/odoo/pull/223715/commits/b857d192085a38b612335223d04f8bdff91b898c

[1]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L698-L703

[2]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L706

[3]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L708

[4]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L477

sentry-7050854871

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

Forward-Port-Of: odoo/odoo#238086

..., pos_online_payment_self_order
Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268)

---

Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page, which triggered the payment transaction post-processing.
However, in some cases, the user never reaches this page.
For example: the user sees that the payment succeeded in their banking app and closes the tab before being redirected to the confirmation page.

To still process the orders, a cron runs every 10 minutes to post-process transactions that were not processed yet.
However, for POS self-orders this is not ideal: we need the order to be processed as soon as possible since we are in direct contact with the user.
A situation where the customer insists their payment went through but the cashier sees no updated order creates unnecessary confusion.

---

To fix this, we now trigger the cron directly after receiving the callback from the payment provider.
This ensures that the transaction (and therefore the order) is always post-processed immediately and kept up-to-date, even if the user never reaches the confirmation page.

Forward-Port-Of: odoo/odoo#235254

pos_online_payment* = pos_online_payment_self_order_preparation_display
Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268)

---

Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page which, once the transaction succeeded, sent the related order to the kitchen (PDIS).
However, in some cases, the user never reaches this page.
For example, the user may see the payment succeed in their banking app and close the tab before the redirection happens.

For POS self-orders, we must send the order to the kitchen as soon as the payment is confirmed to avoid confusion between the customer, the cashier, and the kitchen staff.
Relying solely on the confirmation page was therefore unreliable.

---

To fix this, we now leverage the cron that post-processes payment transactions:
we gather all transactions made in self-order or kiosk mode that are not yet post-processed, and send their corresponding orders to the kitchen.
This ensures that orders reach the PDIS even when the user never lands on the confirmation page.

Forward-Port-Of: odoo/enterprise#99249

The link between purchase order and a repair order break at when the PO is confirmed.

### Steps to reproduce:
* Install the Repair and Purchase modules
* Activate multi-steps routes
* Unarchive the MTO route
* Create a product with the MTO route enabled
* Create a Repair
* On the Repair Order, in part add:
	- type : ADD
	- product : mto product
* Save the RO
* Go to Purchase Order
* Confirm the PO
-> Issue Smart link between PO and RO broken.

### Observation:
The smart link is defined on:
RO -> PO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/repair_order.py#L15-L17 PO -> RO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/purchase_order.py#L15-L17

When we confirm the PO, from the picking information it will create new moves:
https://github.com/odoo/odoo/blob/2c87f3b2b397f268f0e50cb73cd81de992ddd42e/addons/purchase_stock/models/purchase_order.py#L293-L298

To create those stock moves, we go into_create_stock_moves where, for each POL, we will generate their values and erase the smart link:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_stock/models/purchase_order_line.py#L362-L365

### Origin:
In this commit https://github.com/odoo/odoo/commit/9d98c43581e2579f43b35541b43264866dede5a5:
"`created_purchase_line_id` is cleared after confirming the RFQ. This
allows to merge more in `_merge_moves`."
This breaks the link between PO <-> RO to maybe merge the move in the future.

This issue is not present in 19.0 since it was solve in this commit :
https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a

### About the fix:
The root cause of this issue remains ambiguous despite the analysis. Therefore, in the interest of stability and caution, we opted to implement the fix in a safer location.

opw-5121816

Forward-Port-Of: odoo/odoo#232999

**Steps to reproduce:**
- Install `Data Cleaning` app
- Activate notification in Odoo in the admin user profile
- Create a few duplicate contacts
- Go the the "Data Merge: Find Duplicate Records" scheduled action
- Run the action manually
- You should see new notifications telling you that they found potential duplicates
- In the top right MessaginMenu click on the notification, it opens a chatter
- Try to send a message in the chat window
- Traceback : `AttributeError: 'data_merge.model' object has no attribute '_get_thread_with_access'`

**Issue:**
The model doesn't inherit `mail.thread` so it uses `self.env['mail.thread']` directly to send notification:
```
self.env['mail.thread'].sudo().message_notify(
    ...
    model=self._name,
    notify_author=True,
    partner_ids=partner_ids,
    res_id=self.id,
)
```
But when sending the information with the `model` and `res_id` parameters the newly created `Store` uses `self.add("mail.thread", {"id": data.id, "model": data._name, **values})` and the message is assigned to a non-existing thread in the frontend.

**Fix:**
Explicitly check if the message is a `user_notification` and redirect the user to the discuss inbox if it's the case by reapplyng part of https://github.com/odoo/odoo/commit/b3be992c57dc5e412a127d05fc50b059814523aa

opw-5101510

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

Forward-Port-Of: odoo/odoo#238563
Forward-Port-Of: odoo/odoo#234737

When setting options like "Loop" or "Hide Player Controls" on an
embedded Vimeo video, these settings were not applied on the final
page after saving.

Steps to reproduce:
===================
- Go to the Website editor.
- Drag and drop a "Media List" or similar snippet.
- Double-click the video placeholder to open the media dialog.
- In the "Video" tab, paste a Vimeo URL.
- Enable "Loop" and/or "Hide Player Controls".
- Save the page.
-> Observe that the video does not loop and the controls are still
  visible.

Cause:
======
When rebuilding the iframe, `generateVideoIframe` was processing the
video's `src` URL through using `escape()` function. This function
is designed to prevent XSS by converting characters like
`&` into their HTML entity equivalent, `&`.

However, Vimeo video URLs use the `&` character to separate query
parameters (e.g., `?loop=1&controls=0`). The `escape()` function
was converting this URL to `?loop=1&controls=0`. but `setAttribute`
already handles URL values safely. so Vimeo player will receive url
containing &.
This broke the URL's structure. The Vimeo player received a malformed
URL, could not parse the parameters correctly, and therefore ignored
the options for looping and controls.

escape was used before cause  The original code was adding the iframe
using `.html(...)`
see commit: https://github.com/odoo-dev/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33

side note 1: before saving the vimeo video works because we render it
without the double escaping of & (as will be the case for saved video
if this PR is applied)

side note 2: the issue of double escaping also apply to youtube, but it
seems to be ok with superfluous & in URL while in vimeo:

https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1
has the video that doesn't loop, is not muted (so doesn't auto play in
an iframe on most browser) and show controls
https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1:
all option works

Solution:
=========
The unnecessary `escape()` call has been removed.
since the video should be only added using media dialog and the
`setAttribute(...)` will escape it by default

opw-5225261

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

Forward-Port-Of: odoo/odoo#238040
Forward-Port-Of: odoo/odoo#236677

The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:
https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed.

#### Fix:

Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks.

#### runbot-226734

Forward-Port-Of: odoo/enterprise#101268
Forward-Port-Of: odoo/enterprise#100746