Description
------------
Fix a performance issue in the partner search functionality used in the sharing widget. The problem was related to the PostgreSQL query planner choosing a suboptimal execution plan when using a limit of 4 records.

With a very low limit of 4, PostgreSQL would choose to perform an index scan on the `complete_name` index instead of using the more efficient trigram indexes. This resulted in high I/O operations as it traversed the index from A until finding matches, causing significant performance degradation.

The fix simply increases the limit to 8, consistent with other `name_search` operations, ensuring the query planner consistently chooses the trigram index path regardless of the search term.

Benchmark
----------
On a database with over 8 digits count of partners, a non selective search of a partner (5 chars) took:

| Before | After | Speedup |
|--------|-------|---------|
| 27.4s  | 42ms  | 652x    |

Reference
---------
task-4686893

Forward-Port-Of: odoo/enterprise#82680

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

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

opw-4480104

Forward-Port-Of: odoo/enterprise#82643
Forward-Port-Of: odoo/enterprise#81850

Steps to reproduce the bug:

- Create a storable product “P1”:
  - Create a BoM
  - Go back to the product form and create an ECO:
    - Apply on: “Bill of Materials”
    - The created BoM will be selected automatically.
    - Save.

- Return to the product form.
- The ECO count in the smart button is 1.
- Click on it.

Problem:
No ECO is displayed because the domain filters only ECOs applied to the product:
https://github.com/odoo/enterprise/blob/ec6b4717f49ccd5b651be80aed21494ed500f580/mrp_plm/models/product.py#L17-L20

Solution:
only ECOs of type "Product" should be counted in the product form.

Issue 2:

- Try updating the "Apply on" field of the ECO to “Product.”

Problem:
The "Bill of Materials" field becomes invisible but is not cleared. As a result, when counting the number of ECOs linked to the BoM, the count will be incorrect.

https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48

opw-4653598

Forward-Port-Of: odoo/enterprise#82576

[FIX] hr_appraisal: prevent TypeError for raw record data

The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None.
This occurred because the code attempted to create a set from the None value directly.

Steps to reproduce:
-------------------
* Open Appraisal app and click on an employee's card
* Activate debug mode
* From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+

> Observation: 
  File "/data/build/enterprise/hr_appraisal/models/hr_appraisal.py", line 539, in read
    check_notes = set(fields) & {'note', 'assessment_note'}
                  ^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

Why the fix:
------------
set() requires an iterable. By adding this condition, we avoid iterating over NoneType. This maintains the intended default functionality while preventing the crash.

opw-4631142

Forward-Port-Of: odoo/enterprise#82711
Forward-Port-Of: odoo/enterprise#81758

Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user.

**Steps to reproduce:**
- Install the `account` and `l10n_hr_payroll` modules.
- Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record.
- In **Scheduled Actions**, manually execute `Payroll: Update data`.
- Observer the backend error.

**Error:**
`ValueError - ParseError('while parsing /home/odoo/src/enterprise/saas-18.2/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data...`

The error occurs because the method at [1] attempts to load the `hr_salary_rule_ind_emp_data.xml` file that references a deleted `partner_id` [2], leading to a parsing error.

[1] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/models/hr_payslip.py#L44-L54
[2] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data.xml#L364

This commit ensures that `res_partner_data.xml` is loaded before `hr_salary_rule_ind_emp_data.xml`, preventing errors due to missing partners.

Sentry - 6429993371

Forward-Port-Of: odoo/enterprise#81917