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

This is more an UX problem rather than a bug.

In the reconciliation tool, when you reconciled all the transactions of the current filter, rainbow mans appears.

Then, all the background behind the rainbow overlay is disabled, you can no longer edit the filters in the search for instance, and the only buttons available become "All transactions" and "Back to dashboard". Both buttons will make you loose your search filters:
- You loose the "Not Matched" filter which is set automatically when you hit the "x to reconcile" button in the accounting dashboard, and hence you see the already reconciled transactions, while you were actually interested only in the non-reconciled transactions
- If you made a complicated filter, you loose them all and you are good to redo them all.

This revision offers the possibility to have the background behind the rainbow overlay clickable, so you would be able to change the filters, for instance only the last filter, in order to continue your reconciliation where you were, instead of being completely reset.

Before:


https://github.com/user-attachments/assets/4ed7cf41-1fa0-4efe-92a0-171011b4713a


After:

https://github.com/user-attachments/assets/e4f2d580-9dca-4331-9e66-89efeb00edef

…mesheet

**Issue**
In a subscription, the qty delivered of a SOL with "Prepaid" invoicing policy
wasn't updated when timesheets were added.

**Steps to reproduce**
1. Have a service subscription product with an invoicing policy "Prepaid/Fixed
price" and creating a task on order.
2. Create a monthly subscription with a start date 15 days in the past
3. Add some timesheet hours on the task.
4. Run the "Subscription: generate recurring invoices" cron.
- Actual: quantity delivered on the SOL stays at 0.
- Expected: timesheet hours falling during the subscription period are added
to the delivered quantity of the line.

**Cause**
Commit https://github.com/odoo/enterprise/commit/a6420bdacab3b9c9f440f48db3b442e6b6c7b655 added a new module overwriting
the computation of the delivered quantitiy for recurring lines based on
timesheets, for products with an invoicing policy `delivered_timesheet`.
However, the computation is overriden for all timesheet lines selected by
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L11-L12

A second filtering is applied later
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L21
Which exluces products with an invoicing policy different than
`delivered_timesheet`

**Solution**
For products with a "prepaid" invoicing policy, compute the delivered
quantities the same way: the timesheets delivered during the subscription
period.
Note that as explained in a comment, `Side effect: It won't work for the
first period if the invoice cron never run. (the next invoice date has never
been incremented)`

opw-4509495

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings, activate "SEPA Direct Debit (SDD)"
- Create a contact:
  * Country: Belgium
  * Bank Account: [a Belgian IBAN]
- Go to "Accounting / Customers / Direct Debit Mandates"
- Create a mandate for the created contact
- Validate the mandate
- Create an invoice for the created contact as customer
- Confirm the invoice
- Pay the invoice with "SEPA Direct Debit"
- Print the invoice

**Issue:**
The information explaining that the invoice has been paid using direct debit and that the invoice should not be paid manually is not printed on the invoice.

**Cause:**
This information is printed if "sdd_mandate_id" field of the invoice is set.
"sdd_mandate_id" is a related field to "origin_payment_id.sdd_mandate_id" field.
However, since the refactoring on "account.payment", "origin_payment_id" is not set on an invoice anymore.
It is just set on the journal entry linked to a payment.
Therefore, we cannot rely on that field anymore to print the SDD mandate payment information.

**Solution:**
The "matched_payment_ids" field can be used instead.
It's a Many2many field referring all payments linked to the invoice.
If one of these payments has "sdd_mandate_id" set, the SDD mandate payment information is printed on the invoice.

opw-4672191

**Current behavior:**
`expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios.

**Expected behavior:**
Accurate price per unit of component.

**Steps to reproduce:**
1. Create a finished product with a BoM:
* has a 1:1 comp to final ratio with quantities greater than 1 (e.g., 2 units component producing 2 units final)
* make component cost $100 for sake of example
* has a workorder with a workcenter with capacity sufficient to handle full BoM quantity producing (so 2 if used 2 -> 2 on BoM)

2. Create & process MO for finished product

3. Open the Production Analysis pivot view in the mrp app

4. In the `Measures` dropdown, check the `Expected Component Cost / Unit` field -> see that it shows `$50 / unit` instead of the expected `$100 / unit`

**Cause of the issue:**
This per unit value is divided by the BoM `product_qty` 2x:
1: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_account_enterprise/reports/mrp_report.py#L184
2: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_workorder_hr_account/report/mrp_report.py#L32

**Fix:**
Remove the additional division operation in
`mrp_workorder_hr_account`

opw-4474710

Forward-Port-Of: odoo/enterprise#80560

[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