When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback.

Steps to reproduce the error:
- Install ``hr_recruitment`` module with demo data
- Go to Recruitment > Applications > Talent Pools > Create a new pool
- Go to Recruitment > Applications > All Applications > Create a new application with valid email >
  Click Add to Pool > Select the Talent Pool > Add to Pool
- Duplicate the created talent record
- Create another application with the same email > save > click Talent Pools

Traceback:
```py
ValueError: Expected singleton: hr.applicant(2, 1)
```

https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859
Here, the talent is searched using matching applicant information.
When a matching talent has been duplicated, the search returns multiple records.
Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error.

Solution:
Restrict the duplication of talent.

sentry-7556261128

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

Forward-Port-Of: odoo/odoo#273565
Forward-Port-Of: odoo/odoo#270827

Currently, when a user creates and confirms a scrap order for a product that has multiple lots, only a quantity of 1 is being scrapped instead of the full intended quantity.

## Steps to replicate:
* Install Inventory and enable Lots and Serial Numbers from settings
* Create a product 'screw' tracked by lots.
* Create two lots for the product with on hand quantity of 100 on each lot.
* Create a scrap order > Set lot to second created lot > Set quantity to 50
* Save and confirm the scrap order.
* Go to screw and check the on hand quantity

## Observed Behavior:
Only a quantity of 1 from the lot has been scraped, which is incorrect. According to the scrap order, a total quantity of 50 should have been scraped.

## Root cause:
This issue arises from how inverse methods are triggered when the form is saved.

When saving, the `_set_quantity` method is executed first for the quantity field. This method calls `_set_quantity_done`, which in turn invokes `_set_quantity_done_prepare_vals` [1].

At this stage, there are no existing move lines. As a result, the initial loop in [1] is skipped. Because no move lines are present, the system proceeds to reserve quantities using `_get_reserve_quantity` [2].

Since no `lot_ids` have been set yet (because `_set_quantity` is executed before lot assignment), the reservation follows the warehouse’s default removal strategy, which is FIFO. Consequently, it selects quantities from Lot 1 first.

These reserved quants are then used to prepare move line values [3]. The lot information is taken directly from the quant itself [4], resulting in move lines being created with Lot 1.

**At this point, the system state is:**
**Stock move:**
| Field | Value |
|--------|--------|
| Lot IDs | 2 |
| Quantity | 50 | 
 
 **Stock move line:** 
 | Field | Value |
|--------|--------|
| Lot ID | 1|
| Quantity | 50 | 
 

Next, the inverse method for setting lots, `_set_lot_ids`, is triggered. Since the lot on the move (Lot 2) does not match the lot on the move line (Lot 1), the system schedules the existing move line for deletion (as shown in [5]).

Additionally, because the move’s lot (Lot 2) is not present in the move lines, a new move line is created with at [6]:
**Lot ID :** 2
**Quantity:** 1

<h3>Why didn’t this issue occur in earlier versions?</h3>
In previous versions, scrapping was handled by a separate model (stock_scrap). Move lines and move values were only created when the scrap operation was confirmed.

However, after this [commit](https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba), the `stock_scrap` model was merged into the stock move model. Due to this change, inverse methods are now triggered directly when interacting with the scrap form view, leading to the behavior described above.

[1]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L2332-L2399 [2]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L2388-L2398 [3]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L2396 [4]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L1755-L1764 [5]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L618-L620 [6]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L632-L641

## Solution:
By passing `lot_ids` in the context during scrap creation, the system can reserve quantities from the correct lots when setting quantities. This ensures that the lot assignment is consistent from the beginning.

As a result, the `_set_lot_ids` logic executes correctly, avoiding unnecessary deletion of existing move lines that would otherwise occur due to mismatched lots between the move and its move lines.


opw-6109494

When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback.

Steps to reproduce the error:
- Install ``hr_recruitment`` module with demo data
- Go to Recruitment > Applications > Talent Pools > Create a new pool
- Go to Recruitment > Applications > All Applications > Create a new application with valid email >
  Click Add to Pool > Select the Talent Pool > Add to Pool
- Duplicate the created talent record
- Create another application with the same email > save > click Talent Pools

Traceback:
```py
ValueError: Expected singleton: hr.applicant(2, 1)
```

https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859
Here, the talent is searched using matching applicant information.
When a matching talent has been duplicated, the search returns multiple records.
Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error.

Solution:
Restrict the duplication of talent.

sentry-7556261128

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

Forward-Port-Of: odoo/odoo#273565
Forward-Port-Of: odoo/odoo#270827

Currently, when the user scraps a component during a manufacturing order, the system can still consume the same lot/serial number during production, leading to double consumption even when the product is no longer available in inventory.

## Steps to produce:
- Install the Manufacturing app.
- Enable 'Work Orders' and 'Lots & Serial Numbers' from the settings.
- Create two products: 'Car' and 'Engine'.
- Configure 'Engine' to be tracked by 'Serial Number' and update its on-hand quantity to 2 using two different serial numbers.
- Create a Bill of Materials (BoM) for 'Car' with 'Engine' as a component.
- Create a work center named 'Car Assembly'.
- Go to Manufacturing > Configuration > Operations.
- Create a new manufacturing operation named 'Engine Insertion' with:
  - Bill of Materials: 'Car'
  - Work Center: 'Car Assembly'
- Create and confirm a new Manufacturing Order (MO) for 'Car'.
- Open the related work order and start the operation.
- From Actions > Scrap, scrap the 'Engine' serial number currently reserved for the MO.
- Click Produce All.
- Open the product view for 'Engine' and check the on-hand quantity.

## Observed behavior:
Even after the user scraps the product during the work order, the system still allows the same serial-numbered component to be consumed during production. This results in negative on-hand quantities and creates inconsistencies in inventory and manufacturing data.

## Root cause:
When the user starts the work order, the `button_start` function [1] is called. This sets the `qty_producing` field, which triggers its inverse method `_set_qty_producing`. As part of this flow, the component move is marked as picked at [2]. This, in turn, triggers the inverse method of the `picked` field, which marks all move lines in the move as picked, as shown at [3].

Later, when the user scraps the same serial-numbered product, the `do_scrap` function is called. This invokes `_action_done` at [4], which further calls `_action_done` on the move lines at [5]. During this process, `_free_reservation` is executed at [6].

However, because the move lines were previously marked as picked, they no longer satisfy the domain condition at [7]. As a result, they are not unlinked at [8]. This leaves the reservation intact and eventually causes the scrapped component to still be consumed when the user produces the quantity on the manufacturing order.

**Why does this issue not occur in saas-19.3?**
This issue no longer occurs in saas-19.3 after this [commit](https://github.com/odoo/odoo/commit/bb56600bfc81b9a6573a867df93a706de8154d0a), which removed the manual consumption field. As a consequence, move lines are no longer marked as picked when starting work orders, preventing the inconsistent state that leads to this issue.
[1]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/mrp/models/mrp_workorder.py#L659-L660 [2]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/mrp/models/mrp_production.py#L1417-L1421 [3]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move.py#L287-L290 [4]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_scrap.py#L152-L158 [5]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move.py#L2125 [6]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move_line.py#L696-L700 [7]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move_line.py#L807-L817 [8]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move_line.py#L851
## Solution:
When a component move line is scrapped, it should be unpicked so that the system can reserve the next available lot/serial number automatically.

Once a component has been physically scrapped, it no longer makes sense to keep it marked as picked and reserved. Doing so leaves the MO in an inconsistent state, where the system still considers the scrapped component usable. By unpicking the move line after scrapping, both the system and the user clearly see that there is no longer any reserved quantity associated with that component.

This also allows system to automatically pick from next available lot or serial number, ensuring the manufacturing process can continue smoothly.

Such behavior is especially important in shop floor scenarios, where mistakes or damages may occur after components have already been registered, and the manufacturing process should continue without interruption.


opw-6157406

Forward-Port-Of: odoo/odoo#264589