_Note: The main fix of this PR (the orm one) raised an error in CRM, 
a test was working thanks to some cache pollution (cf description of crm
commit). The below text only shows the description of the orm commit._

The use of a computed inverse o2m field does not correctly work when
creating the record of the main model.

To reproduce:
(Need stock)
1. In Settings, enable "Storage Locations"
2. Create a new Storage Category
   - Make sure to have one Capacity by Product

Error: on save, the Capacity by Product disappears. Yet, if the user
reloads the page, the capacity will be back.

First, few details about the Storage Category model. We are dealing
with the field `product_capacity_ids`, a computed inverse o2m field:
https://github.com/odoo/odoo/blob/e5e3a3f7bf3770fe2bba11b501870d4fb7ef2e51/addons/stock/models/stock_storage_category.py#L15
Its content is a subset of the `capacity_ids` field:
https://github.com/odoo/odoo/blob/e5e3a3f7bf3770fe2bba11b501870d4fb7ef2e51/addons/stock/models/stock_storage_category.py#L14
So, its compute simply get a subset of `capacity_ids` and its inverse
will write some values on `capacity_ids`:
https://github.com/odoo/odoo/blob/e5e3a3f7bf3770fe2bba11b501870d4fb7ef2e51/addons/stock/models/stock_storage_category.py#L39-L41

Now, back to the issue. When we `web_save` the category, at some
point in the create process, it leads here
https://github.com/odoo/odoo/blob/bdb24afbf85f4d58722db493f725dd95c5780ff7/odoo/orm/models.py#L4389-L4408
Where we want to resolve all the pending inverse. To do so, we first
update the cache (L4401) and we then call the inverse methods (L4408).
In the above case, it means that we first update the value of
`product_capacity_ids` in the cache. The value we are passing is a
`Command.CREATE` value. In that case, when converting the value for
the cache, we actually create a `NewId` record:
https://github.com/odoo/odoo/blob/ae55f5b494005a1e7566c819592f7dd64623c3fd/odoo/orm/fields_relational.py#L513-L516
When running the inverse, we write this record on `capacity_ids` (cf
the code quoted above). This will lead to the actual creation of the
capacity record.

But... Here is where the problems begin: we have updated the cache
with a `NewId` value and define `capacity_ids` with an existing
record. However, we don't update anything in the cache. As a result,
at the end of `web_save`, we do a `web_read`. It will lead here:
https://github.com/odoo/odoo/blob/bdb24afbf85f4d58722db493f725dd95c5780ff7/odoo/orm/models.py#L3427
Where we convert the value of `product_capacity_ids`. Since
available in the cache, we will use the `NewId` value and convert it,
i.e.: we will return the `.ids` of the recordset:
https://github.com/odoo/odoo/blob/ae55f5b494005a1e7566c819592f7dd64623c3fd/odoo/orm/fields_relational.py#L569-L570
Which means... The actual IDs, excluding the `NewId` one.

This explains why the line suddenly disappears on save. Then,
reloading the page will trigger the compute based on `capacity_ids`.
This field is correctly defined, so will do the compute -> the line
will appear.

Since we update the cache to compute the inverse, we should then
clear that cache to ensure proper consistency with what happened
during the inverse.

OPW-4915087

Forward-Port-Of: odoo/odoo#222763

### Steps to reproduce:

- Go to the To-Do app and type something in the editor.
- Select the typed text.
- Click on the Font Size Input and choose a value from the dropdown (e.g.,80).
- Try typing again in the editable area.
- Selection is still visible, the focus is no longer in the editable area.

### Description of the issue/feature this PR addresses:

- `focusEditable()` skipped restoring focus if the selection was inside the editor, even when the editor itself wasn’t focused.
- When the font size input (inside an iframe) is focused, editable loses focus.
- Selecting a value from the dropdown blurs the iframe input, but focus is not returned to the editable area.
- As a result, the selection is still visible but the user cannot type.

### Desired behavior after PR is merged:

- Does nothing if the editor or its descendants have focus.
- Focuses the editor if needed.
- Restores selection only when it's outside the editor.
- When the iframe input is blurred, focus is returned to the editable area.

task-4932364

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

Forward-Port-Of: odoo/odoo#222360
Forward-Port-Of: odoo/odoo#218774

**Issue:**
Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS

**Cause:**
The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty` to the related `sale_line` each time it runs

When there is no PoS order, the method add 0 to the line, so the expected behavior work But when you have a PoS Picking, a quantity was added to `qty_delivered` each time the `rental.order.wizard` is used The issue also occured earlier when the `flush_all()` is called in `_process_order()`

**Fix:**
There is already a `_compute_qty_delivered` method in `pos_sale_stock_renting` that override the `qty_delivered` But it's restricted by `_are_rental_pickings_enabled()` That's not necessary because we don't use any `stock.picking` in the `_compute_qty_delivered` function, only `stock.move` so we removed that verification

To make the code working, we also need to extend the _get_outgoing_incoming_moves() results Because there were also block by a `_are_rental_pickings_enabled()` condition even if there is only moves here We need all the moves to calculate `qty_delivered` properly

**Steps to reproduce:**
- Create a New Product "Rental PoS" that Can be Rented
- Create and confirm a New Rental Order, with any customer and your product
- Open a PoS Session
- Click on Quotation/Order
- Choose the last Order and Settle the order
- Click on Yes (to confirm import to PoS)
- Click on Payment, select Cash and Pay
- Go in the Backend, and to your RO
- Click Return and Validate
- Before the fix, the Delivered should be 2.0

opw-4877019

Forward-Port-Of: odoo/enterprise#93358
Forward-Port-Of: odoo/enterprise#90510

Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total between the sale and pos app.

Steps to reproduce:
-------------------
* Modify the product precision to have 4 digits
* Modify the burger menu combo product
  * Sale price 26.5
  * Burger choice: Cheese burger, remove taxes, change price to 10
  * Drinks choice: Coca cola, remove taxes, change price to 10, extra price set to 4.5
  * Add another combo choice with 1 product only, no tax, price 10
* Open pos session
* Add the combo, select the product that were modified
> Total is 31.01 when it should be 31.00

Why the fix:
------------
Point of sale was using the decimal precision set on the product price to compute the price unit of the child lines. We can notice that the sale app was using the currency precision.

We will use the same approach as sales. The decision was driven by the fact that 1) both scenarios could make sense, 2) total should be as set, 3) child line prices are not as important as the total and don't have a big influence.

opw-4769227

Forward-Port-Of: odoo/odoo#220352

…ml internal dropship return

**Problem:**
when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will create an account move that credits "stock valuation" instead of debitting it

**Steps to reproduce:**
- enable the "Anglo-Saxon Accounting","Multi-steps routes" and "Subcontracting" settings
- create a storable product with dropshipping route and a vendor
- in 'general information' write a non null cost
- make sure the product category's inventory valuation' is 'automated'
- create a new quotation for this product, confirm it and confirm the linked purchase order
- click on the dropship smart button and validate the picking
- click on return and select 'Physical Locations/Subcontracting Location' as the return location
- validate and click on the valuation smart button
- on the only stock valuation layer for this move, click on the book shaped widget

**Current behavior:**
the account move credits Stock Valuation and debits stock interim (received)

**Expected behavior:**
As we are returning the product to stock it should increase the value of the stock valuation account.
Therefore, it should debit stock valuation and credit stock interim (received)

**Cause of the issue:**
If the mrp_subcontracting_dropshipping module is active, and if we call _is_dropshipped_return on a stock move which is the return (to the subcontracting location) of a dropshipped move : the method will return true. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L29-L35 Therefore, inside _account_entry_move, _is_in will be false (contrary to if mrp_subcontracting_dropshipping is not installed or if the destination is another internal location)
https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L580 The aml vals will be computed inside _prepare_anglosaxon_account_move_vals https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L596 Here the fact the destination location is internal does not change the fact that it should debit the stock valuation account (meaning it should used acc_valuation as the second parameter of _prepare_account_move_vals) if the cost is positive. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L610-L614

opw-4894755

Forward-Port-Of: odoo/odoo#221771
Forward-Port-Of: odoo/odoo#221009

Steps to reproduce
==================

- In debug mode
- Go to Contacts
- Open any record
- Open studio
- Click on any field
- Add the "Extra rights / Technical Features" group to "Allow visibility to groups"

=> The group is not displayed as a tag

- Restore the view
- Now without debug mode (?debug=0), repeat the same steps

=> The field disappears, we need to toggle "Show Invisible Elements" to see it again

Cause of the issue
==================

https://github.com/odoo/odoo/pull/179354/commits/15aeaf88c268f047b8b83a5aa66f5da246c2b675

When calling get_views, the "base.group_no_one" is removed from the groups attribute and "invisible" is set to true if we are in debug mode.

Solution
========

Adding "base.group_no_one" is still the way to have the expected behavior for now. We override some ir.ui.view functions when in studio to be able to edit it.

According to the docstring of _postprocess_debug_to_cache, this feature is temporary. Another solution will be needed in the future.

opw-4969262

Forward-Port-Of: odoo/enterprise#91647

Currently, an error occurs when trying to remove a move line from a bank statement line if the journal entry contains lines with different reconciliation models.

**Steps to Reproduce:**
1. Install the Accounting module.
2. Duplicate the "Internal Transfer" reconciliation model.
3. Accounting dashboard > click on Bank > create new record.
4. Add the invoice, apply "Internal Transfer" reconciliation model.
5. Edit the balance of the line to lower, apply duplicated model(Internal Transfers (copy)).
6. Try deleting the generated Liquidity Transfer line.

(Refer [this video](https://drive.google.com/file/d/1cz80Q5325x3rqYUlGahVzFIXH2iqrbRF/view?usp=drive_link) for steps to reproduce.)

**Error:**
ValueError - Expected singleton: account.reconcile.model(8, 6)

**Cause:**
In the method `delete_reconciled_line` at [1], the `reco_model_id` is fetched from `self.move_id.line_ids.reconcile_model_id`. If the move contains lines linked to multiple reconcile models, this causes a singleton error during subsequent processing.

**Fix:**
This commit uses the already computed `move_lines_to_remove` to retrieve `reconcile_model_id` instead of accessing it from `self.move_id.line_ids`, which may result in a multi-recordset.

[1] - https://github.com/odoo/enterprise/blob/89aa58029a79928788277489414f8192aa5353e4/account_accountant/models/account_bank_statement.py#L1041-L1049

sentry-6781788260

Forward-Port-Of: odoo/enterprise#91619

**Issue:**
Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS

**Cause:**
The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty` to the related `sale_line` each time it runs

When there is no PoS order, the method add 0 to the line, so the expected behavior work But when you have a PoS Picking, a quantity was added to `qty_delivered` each time the `rental.order.wizard` is used The issue also occured earlier when the `flush_all()` is called in `_process_order()`

**Fix:**
There is already a `_compute_qty_delivered` method in `pos_sale_stock_renting` that override the `qty_delivered` But it's restricted by `_are_rental_pickings_enabled()` That's not necessary because we don't use any `stock.picking` in the `_compute_qty_delivered` function, only `stock.move` so we removed that verification

To make the code working, we also need to extend the _get_outgoing_incoming_moves() results Because there were also block by a `_are_rental_pickings_enabled()` condition even if there is only moves here We need all the moves to calculate `qty_delivered` properly

**Steps to reproduce:**
- Create a New Product "Rental PoS" that Can be Rented
- Create and confirm a New Rental Order, with any customer and your product
- Open a PoS Session
- Click on Quotation/Order
- Choose the last Order and Settle the order
- Click on Yes (to confirm import to PoS)
- Click on Payment, select Cash and Pay
- Go in the Backend, and to your RO
- Click Return and Validate
- Before the fix, the Delivered should be 2.0

opw-4877019

Forward-Port-Of: odoo/enterprise#93406
Forward-Port-Of: odoo/enterprise#90510

…ay change

**Steps to reproduce**
- Create a public holiday without a calendar during a work day.
- Create a leave for an employee overlapping the public holiday
for a time off type generating Timesheets. Validate it.
- Expected: on the day of the public holiday, no timesheet is
generated for the `hr.leave` to avoid duplication.
- Either delete the public holiday, or set a calendar on it
different than the one defined on the employee.

- Issue: the public holiday timesheet has been deleted, but its
deletion should've lead to the creation of the `hr.leave` timesheet
that we didn't create at the time the public holiday existed.

- Second issue: after that, change the calendar of the public holiday
to the same as the employee's. Still a missing timesheet.

**Solution**
We can use `_reevaluate_leaves` to find the leaves affected by changes
in public holidays.
`_generate_timesheets` then re-generates the timesheets as if the leave
was just validated (the call to `list_work_time_per_day` ignores the
already present resource.calendar.leave).
We also check missing public holidays timesheets to fix the second issue.

opw-4819697

Forward-Port-Of: odoo/odoo#216901

The system failed to evaluate the embedded action, which refers to the Uninstalled module.

Steps to produce:
1. Install `Project` and `Timesheets`.
2. Go to Project and open any project.
3. Click on the embedded action icon and select `Timesheets`.
4. Save the view from the embedded action's icon.
5. Now, Uninstall `Timesheets`.
6. Now, go to that Project and try to open it.

Error:-
`KeyError: 'allow_timesheets'`
`ValueError: Invalid field in filter of project.project:
 [('allow_timesheets', '=', True)]`

Solution:-
- Here,
https://github.com/odoo/odoo/blob/e7efc2c3ad70aa9273412b089a71a9ade75ad525/odoo/addons/base/models/ir_embedded_actions.py#L19

- Also, use `ondelete="cascade"`. but `ondelete="cascade"` not works on `ir.actions.actions`.
https://github.com/odoo/odoo/blob/e7efc2c3ad70aa9273412b089a71a9ade75ad525/odoo/addons/base/models/ir_actions.py#L117-L127

We should remove `ondelete="cascade"` from the `action_id` field and add explicit unlink logic for `ir.embedded.actions`in the unlink method.

Sentry - 6495174314

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

The system gives an error if we set the filter in the relation of lead_properties.

Steps to Produce:
1. Install the `CRM` module.
2. CRM > Configuration > Settings.
3. Enable the `Rule-Based Assignment` and save the changes.
4. CRM > Reporting > Leads, then go to list view.
5. Click on NEW and add the required values.
6. From the gear icon, click on Add properties, set a random value, and then save.
7. CRM > Sales > Teams.
8. Click on the 3 dots of any team and click on Configuration.
9. Add the new salesperson and set the Lead Assignment Filter like Properties > Property 1(name of the property you added in lead form view) - is equal - demo (values of that property that you gave previously) and then save.
10. Click the gear icon and select the CRM: Lead Assignment.

Error:
`AttributeError: ' dict ' object has no attribute '_fields'`

Solution:
The code filters records based on complex domain conditions and combines matching IDs using logical operators. It also supports special fields like properties.

Sentry - 6544761414

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Enterprise: https://github.com/odoo/enterprise/pull/92951

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

Forward-Port-Of: odoo/odoo#223852

Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted.

Steps to reproduce:
- Create a sales order and add a combo product to it.
- Modify one of the combo items by replacing it with another combo product.
- Delete the original parent combo product from the order lines and save.

Error:
`ValueError: Expected singleton: sale.order.line()`

The error occurs because the parent combo item is deleted, which causes `line.virtual_id` to become False. As a result, the filter [1] returns no matching records, and ensure_one() fails by raising a singleton error due to receiving zero records.

This happens because the function [2] called from onchange in `sales_order` [3] that performs all the changes only checks the first level of combo items and doesn’t handle cases where those items are also combo products with their own linked items.

This commit fixes the error by properly deleting all nested combo items in the sales order, ensuring no leftover items from nested combos remain that could cause errors.

[1] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order_line.py#L1567-L1569
[2] - https://github.com/odoo/odoo/blob/57b4056798b9a380027fd3da1c4f3965249a4509/addons/sale/models/sale_order_line.py#L1572-L1591
[3] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order.py#L922

sentry-6653847384

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

Currently, an error is encountered while editing a Reordering Rule which is already related to some confirmed MO.

**Setup:**
- Install mrp and sale_management.
- Create a storable product with the Manufacture route enabled and its on-hand quantity set to 0.
- Create a Bill of Materials (BoM) for the product and also add at least 1 component.
- Create a Reordering Rule for the product with Min Quantity 0 and Max Quantity 0.

**steps to reproduce:**
- Create and confirm a Sales Order for 40 units of the product. This generates a Manufacturing Order (MO).
- Navigate to the generated MO and add a line for Work Order(set Expected Duration: 1000min).
- Edit the product's Reordering Rule (e.g., change the min Quantity).

for steps reference you can use [this video](https://drive.google.com/file/d/120srSySVHI0FzaWCruz0LVIBKCjK4oOL/view?usp=sharing)

**Error:**
`KeyError: 1`

**Root Cause:**
- The KeyError is triggered when a reordering rule is edited. At this moment, the system calls the `_quantity_in_progress` method to update the forecast. This method prepares a results dictionary (res) that only knows about the ID of the record currently being edited (which might be a new, unsaved record with a temporary ID).

- The issue arises in the loop that processes confirmed Manufacturing Orders, at [1], the value of orderpoint.id is still `<NewId origin=2>` and on trying to access it at [1] causing an error

[1]- https://github.com/odoo/odoo/blob/f1e11af050aa4d7be40e5179dc67a74ff81de076/addons/mrp/models/stock_orderpoint.py#L138

**Solution:**
This commit ensures that only valid orderpoint IDs are processed at [1]

Sentry-**6135193468**

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Currently, an error occurs when submitting the 'Send Email' form.

Steps to Reproduce:

 - Install the `website` and `web_studio` modules.
 - Go to `website` > `Click on Edit` > `Drag and drop form`.
 - click the form and in actions select the `more models`, and select
   `outgoing mails(mail.mail)` model and `save`.
 - `Submit` the form, and the error appears in the `logs`.

**Error:**
`KeyError: 'website_form_signature'`

**Cause:**
This error occurs when submitting the "Send Email" form from the
 website. By default, the form action is `"Send an E-mail"`, and when 
the user `changes` the form’s model to outgoing mails (mail.mail), 
which also has the action "Send an E-mail," the system checks the 
existing model [1] and retrieves it. Since `shouldRerender` is set to 
false, [2] is not executed, and as a result, the `email_to(hidden field)` 
is not present in the form. And the website_form_signature is added 
from [3], but due to the condition at [4], the code at [3] is not executed. 
When it is accessed at [5], KeyError is raised.

**Fix:**
This commit ensures that when the user changes the model, 
`rerenderXml` is executed so that the `hidden field` is also added.

[1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156

[2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

sentry-6746753251

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Community: https://github.com/odoo/odoo/pull/223852

opw-5009635

Forward-Port-Of: odoo/enterprise#92951

Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing configuration wouldn't work.

After this commit, we handle the blackbox as a special case, and if the name of the device matches exactly with our existing blackbox, we update its identifier instead of creating a new device.

This does require a new device specific check in the controller which is quite ugly. Another approach would have been to make the identifier of the blackbox equal its FDM ID instead of the serial port, but this was not done for the following reasons:
- Changing the identifier format in stable would cause all existing clients' blackboxes to become unconfigured once their IoT box restarts.
- Making the identifier different to the serial port would require a hack in the blackbox driver to change its own identifier and update the devices dictionary, since the serial interface assumes all devices use the port as their identifier.

task-5055027