### Steps to reproduce:

- In the settings Enable Multi-steps route
- Create a product FP with a BOM:
  - 1 component: 1 x COMP (tracked by SN)
  - 1 operation: "Register SN on COMP"
  - Add an instruction on your op:
    - type: "Register consumed component"
    - Product To Register: COMP
- Put 2 SN for COMP:
  - SN01 in Stock/Shelf1
  - SN02 in Stock/Shelf2
- Create and confirm an MO for 1 Unit of FP
> SN01 is reserved on the COMP raw move.
- Go to the shopfloor > "Register SN on COMP"
- Change the SN of the COMP from SN01 to SN02
#### > Go back to the MO the incorrect location was used

### Cause of the issue:

While the lot is correctly updated by the action here: https://github.com/odoo/enterprise/blob/e90cf74be3945d1f1256d398ca9c4b61bc35ed08/mrp_workorder/models/quality.py#L485-L507 The associated quant is not set and hence the move location_id, package, ... are not updated with it.

### Fix:

We take advantage of the `quant_id` dummy field of the `stock.move.line` to update the info to write thanks to the write override: https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L399-L400 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L911-L920

### Note:

Unfortunately, the Dialog opened when clicking on the the quality check from the shopfloor:
https://github.com/odoo/enterprise/blob/34ab94cdcc49f4ade66953874a03f2988b2b4317/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L12
is not embedded in a form view so that the onchange:
https://github.com/odoo/odoo/blob/366676cafdce00d55823c6daf41452b0c2373e4d/addons/stock/models/stock_move_line.py#L185-L192
is not triggered by our change of "lot_id".

opw-4149941
---

Forward-Port-Of: odoo/enterprise#72816

### Steps to reproduce:

- Create a delivery order for 5 units of a product
- Scan 1 unit and click on the pencil icon to edit the record further
- On the digipad access the backend (for instance by clicking the external link arrow next to the location).
- Come back to the record
#### > The line now displayed a 1/1 but does not records what remains: 0/4.

### Cause of the Issue:

Setting a quantity of 1 on the move line will trigger a write call on the related stock move line to update its quantity. However, when you leave the barcode, even thought it will save these change, it will not split the move in 2 for the barcode app to be able to rely on the backend data to generate a correct sate of the record. Threfore, when you come back to the record, the main component will be regenerated from the backend values of the `get_barcode_data`:
https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L76-L80 And will onlydisplay the "1/1" line that was reported fromt he back end.

### Fix:

The `split_uncompleted_moves` method taking care of splitting the moves for barcode data compatibility:
https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/models/stock_move.py#L9-L11 is already called when you exit the barcode via the exit button: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L228-L231 https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/models/barcode_picking_model.js#L762-L765 
These were added by commit 2eb6465e4f18c701efdf28ea4b8f95f3119d3db8 However, it should IMO be called every time you leave the app that is just before destroying the component. Furthermore, note that it will  only split the moves if a save happend (which is the expacted behavior).

opw-4232106
---

Forward-Port-Of: odoo/enterprise#72453

### Steps to reproduce:

- In the settings Enable Multi-steps route
- Create a product FP with a BOM:
  - 1 component: 1 x COMP (tracked by SN)
  - 1 operation: "Register SN on COMP"
  - Add an instruction on your op:
    - type: "Register consumed component"
    - Product To Register: COMP
- Put 2 SN for COMP:
  - SN01 in Stock/Shelf1
  - SN02 in Stock/Shelf2
- Create and confirm an MO for 1 Unit of FP
> SN01 is reserved on the COMP raw move.
- Go to the shopfloor > "Register SN on COMP"
- Change the SN of the COMP from SN01 to SN02
#### > Go back to the stock MO the incorrect location was used

### Cause of the issue:

While the lot is correctly updated by the action here: https://github.com/odoo/enterprise/blob/e90cf74be3945d1f1256d398ca9c4b61bc35ed08/mrp_workorder/models/quality.py#L485-L507 The associated quant is not set and hence the move location_id, package, ... are not updated with it.

### Fix:

We take advantage of the `quant_id` dummy field of the `stock.move.line` to update the info to write thanks to the write override: https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L399-L400 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L911-L920

### Note:

Unfortunately, the Dialog opened when clicking on the the quality check from the shopfloor:
https://github.com/odoo/enterprise/blob/34ab94cdcc49f4ade66953874a03f2988b2b4317/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L12 is not embedded in a form view so that the onchange: https://github.com/odoo/odoo/blob/366676cafdce00d55823c6daf41452b0c2373e4d/addons/stock/models/stock_move_line.py#L185-L192 is not triggered by our change of "lot_id".

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

Forward-Port-Of: odoo/odoo#185662

Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and memory-expensive because the `purchase_id` field is not stored so it needs to compute the relationship for all moves in the expanded ids due to prefetching. 

Since there exists a Many2many relationship between stock pickings and purchase orders, it's possible to rely on a search query instead of the `mapped` call. Although this might miss some cache optimizations, it's still much more efficient in terms of memory. This is because this approach is not susceptible to prefetch_ids explosion. It's also worth noting that this function is only called on individual stock moves instead of batches as part of the anglo_saxon_accounting logic. That being said, we don't have to worry this much about cache optimization since the method is not batched to begin with.

Using this optimization, we get the following benchmarks. 

Benchmark:
| num stock.move (_prefetch_ids) | time before | no. queries before | time after | no. queries after|
|----|------|-----| ----- | ----- |
| 1000                   | timeout | N/A | ~ 85 seconds | 47897 |

opw-4096108





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

Forward-Port-Of: odoo/odoo#181822

Use cases: send an email to
 "Bike@Home" <info@bike.com>  (name containing @)
 "robert@exampl.com" <robert@example.com> (result of partner name_create)

When there is an email in the name field, emails are sent twice and
thus may be counted twice in various tooling, introduce unwanted or
extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908
combined to https://github.com/odoo/odoo/pull/74474 which improved support of multiemails and
formatted emails in various email input.

This notably leads to better formatted email computation on partner
that generates emails like '"email@example.com" <email@example.com>'
when email is used both as name and email. When sending emails to this
partner only a single email should be sent and counted.

A fix is been done to remove duplicates in that tool, making the returned
list unique. In this PR we allow to receive a pre-validated
list of emails that restricts emails found by 'extract_rfc2822'.
When going through classic flows, we already computed emails using
'email_split' and its subtools, hence we just need the encoding
check of 'extract_rfc2822'. Additional emails found by that tool
are ignored as we consider those are fake emails.

This PR contains tests and fixes related to that issue as well as multi
and formatted emails management.

Task-3704658

Forward-Port-Of: odoo/odoo#186798
Forward-Port-Of: odoo/odoo#185793

Issue:
Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so.

To reproduce:
1. Create a new user.
2. Click ‘Create Employee’ in the user view
3. Go to the employee through the smart button
4. In the tab HR Settings, remove the related user
5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve => Post Journal Entries)
6. An error message about missing vendor (res.partner) appears

Cause:
The field work_contact_id keeps the link between hr.employee and res.partner, and is updated in the function _sync_user. Since work_contact_id=user.partner_id.id, when the user is removed from the hr.employee, work_contact_id is also removed.

Fix:
The link between hr.employee and res.partner should be kept until the user is assigned to another employee. In this case, the partner associated to the user should also be associated with the second employee, and no longer to the first employee.

To do so, _sync_user assigns _origin.user_partner_id to work_contact_id if no user is passed (in case the user is removed). A helper function is called when creating or writing an employee, to unlink the partner and the previous employee in case the user is assigned to another employee.

task-4049996


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

Forward-Port-Of: odoo/odoo#175478