Before this commit, a HOOT test in discuss was failing non-deterministically on runbot:
```
[HOOT] Test "@mail/thread/thread/mark channel as fetched when a new message is loaded and thread is focused" failed:
```

The test should RPC mark as read once but rarely does twice instead. This happens because the condition for mark as read depends on whether the current user has seen the last message[1] and the RPC is not triggered again while marking as read is ongoing[2].

The problem is that "current user has seen" data are received from bus notification, while the "ongoing marking as read" window is until RPC response. This means it will properly make mark-as-read RPC once as long as the bus notification is received before the RPC response.

In rare case the bus notification is received after, then the code[1] will think the user hasn't read the last message and also there's no ongoing marking as read [2] therefore it will trigger a RPC again.

This problem shows a design issue with code flow using both RPC response and bus notifications. RPC response is simpler to understand but doesn't scale with Discuss needs, and since recently bus notifications did not work in tours so we were tempted to make discuss work a bit in tours thanks to RPC responses.

One idea to solve this problem would be to rely solely on bus notifications, so every flow that expects RPC return should actually await the related bus notification response. While we are deciding on this topic, this commit just relax the test to assert at least one "mark as read".

In practice a user may sometimes "mark as read" twice, but this is a known and minor issue for now until we find a better design to fix this problem once and for all.

[1]: https://github.com/odoo/odoo/blob/saas-18.2/addons/mail/static/src/discuss/core/common/thread_model_patch.js#L337
[2]: https://github.com/odoo/odoo/blob/saas-18.2/addons/mail/static/src/discuss/core/common/thread_model_patch.js#L357

runbot-223240

Versions
--------
- 17.0+

Steps
-----
1. Have a partner with a `commercial_partner_id`;
2. for the `commercial_partner_id`, create an partner of type `invoice`;
3. create & confirm a sale order invoiced to the initial partner;
4. create & confirm a sale order invoiced to the invoice partner;
5. check the `credit_to_invoice` of the partner;
6. check the `credit_to_invoice` of the `commercial_partner_id`.

Issue
-----
The credit to invoice is twice what it should be.

Cause
-----
The `_compute_credit_to_invoice` method sums up the `credit_to_invoice` on a partner's `commercial_partner_id`. By first checking the partner's credit to invoice, it searched all sale orders credited to the commercial entity. Before it can sum these, it first has to compute the `credit_to_invoice` of the `commercial_partner_id`, which retrieves the same sale orders, and hence get summed up twice.

Solution
--------
Only compute the `credit_to_invoice` on commercial partners by taking the intersection of `self` & `self.commercial_partner_id`.

opw-4855507

Forward-Port-Of: odoo/odoo#214343
Forward-Port-Of: odoo/odoo#213849

### Steps to reproduce:

- Create a storable product
- Click on the Forecast smart button > Replenish
- Process the dialog or close it
#### > Your browser will crash as you just started an infinite loop this can be seen in the logged by an infinite amount of `search_read` on the stock.warehouse model made to render the template an infinite amount of time.

### Cause of the issue:

Closing on replenish will open a dialog. Closing this dialog will in turn call its `_onClose` method:
https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/stock/static/src/stock_forecasted/forecasted_buttons.js#L26-L28 Now the issue is that `res` does nto contains a special key and hence the `reloadReport` call will execute an `ir.actions.client` to relaod the forecast page:
https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/stock/static/src/stock_forecasted/stock_forecasted.js#L97-L106 This is highly problematic since executing such an action will call the `_updateUi` method and hence close all existing dialog: https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/web/static/src/webclient/actions/action_service.js#L1274 https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/web/static/src/webclient/actions/action_service.js#L1111 Since our dialog hasn't been closed yet this will in turn call back the `_onClose` that started this call resulting in this chain of action: `_onClose -> updateUi -> closeAll -> _onClose -> ...` And, since the `noReload` parameter is not used in our `_onClose` we end up in an infinite loop.

### Note:

The infinite loop has become possible since saas-18.1 see commit d606be75c44fccf0b1ddf5216892f1d4b7162686
which changes the order on which a dialog is closed and its call back  method called (onClose). Prior to that change the dialog was closed and  then its call back called. It is now the opposite so that if the onClose of a dialog triggers an action closing all dialogs, it will in turn call the onClose of the dialog one more time. The way to avoid infinite recursion is therefore to ensure that the `noReload` parameter of the onClose is correctly used as introduced here:
https://github.com/odoo/odoo/commit/d606be75c44fccf0b1ddf5216892f1d4b7162686#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dL1123-R1108

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

Forward-Port-Of: odoo/odoo#214191

When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number.

This happens because the method checks for the absence of both `picking_type_id`, `is_inventory`, and `lot_id`, assuming a lot is always mandatory outside inventory and picking flows.

However, scrap operations may occur outside these flows and should not necessarily require a lot, especially when triggered programmatically (e.g. via API or automation), bypassing the form view validation.

This commit updates the condition in `_action_done()` to check the context key `is_scrap`, which is already passed in `do_scrap()` via `move.with_context(is_scrap=True)._action_done()`.

This allows tracked products to be scrapped without a lot in valid scenarios, without misleadingly assigning a `picking_type_id` to the move.


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

Forward-Port-Of: odoo/odoo#213536
Forward-Port-Of: odoo/odoo#206900

### Description:

Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues.

### Fix:

`_compute_picking_ids`, is improved by moving its search outside the loop and grouping by `group_id`, reducing the amount of calls to the ORM.

A `skip_activity` context check is added in `_action_cancel` to bypass activity generation during cancellation, aligning with the existing check done later in `_log_activity_get_documents`.

Also, a bug in `_action_cancel` was calling a filtering on`self`, rather than `production`, and that for each production, which was degrading the performance.

### Benchmark:

| N° of MO | Before | After |
|----------|--------|-------|
|       80 |    15s |    1s |
|      160 |    33s |    2s |
|     1000 |   2:52 |    8s |

### Reference:

opw-4734710

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

Forward-Port-Of: odoo/odoo#214347
Forward-Port-Of: odoo/odoo#207960

to_reproduce:
---
1. Create a combo product (no company set)
2. Create a combo choice (no company set)
3. Add a product with company restrictions
4. Multi-company error appears: "Incompatible companies on records"
5. Set company on combo choice and product template - error resolves
6. Remove company from both combo choice and combo product template
7. Save succeeds despite invalid company configuration

problem:
---
- During combo choice updates, only the modified combo items are included in vals['combo_item_ids'], while existing unchanged combo items are not added to the validation scope.
 https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L68
- The company validation logic only checks items present in the vals,  missing the existing combo items that should also be validated for company consistency.
https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L1092

solution:
---
- Add another check on combo items

opw-4844678

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

Forward-Port-Of: odoo/odoo#213615

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.

Steps to reproduce:
- Create a product P1 with a BoM that includes:
  - Component 1 (sequence = 1)
  - Component 2 - KIT (sequence = 2), which itself contains:
      - Component 2-1 (sequence = 1)
      - Component 2-2 (sequence = 2)
  - Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.

Observed behavior:
- The generated stock moves are ordered as:
    1. Component 1
    2. Component 3
    3. Component 2-1
    4. Component 2-2

Expected behavior:
- The stock moves should respect the BoM line sequence:
    1. Component 1
    2. Component 2-1
    3. Component 2-2
    4. Component 3

Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430

Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.

opw-4809095

Forward-Port-Of: odoo/odoo#212761

### Steps to reproduce:

- Insert an image into the editor.
- Open the Transformation controls for the image.
- Press the `Backspace` key to delete the image.
- The transformation overlay remains visible after the image is removed.

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

- In commit [1](https://github.com/odoo/odoo/commit/85698bf4f591fc9280f054b9a255a7d5ff4d1fe2), the `image_transform_button` component unmounted before `selectionchange` event could fire.  As a result, event listener was removed, and the transform container was not closed when the image was deleted.

Desired behavior after PR is merged:

- The `selectionchange` listener is now attached within the `image_transformation` component.
- A `keydown` listener is also added to explicitly handle Backspace and Delete keys, addressing the case where Chrome does not trigger `selectionchange` on image deletion.

task-4831728

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

Forward-Port-Of: odoo/odoo#212715

**Issue**
When viewing an invoice in Spanish, the "Outstanding credits" section may overflow or be cut off on the right side.

**Steps to Reproduce**
1. Install the Accounting module.
2. Switch the user language to Spanish.
3. Navigate to Contabilidad > Clientes > Facturas.
4. Open an invoice that has outstanding credits.
5. Set the browser zoom to 125%.
6. Observe that the outstanding credits widget content is truncated or overflows its container.

**Root Cause**
The field `invoice_outstanding_credits_debits_widget` was placed directly in the form without a layout container, causing it to misalign and overflow in cases where translated text or zoom scaling increased its width. The lack of a proper responsive layout prevented it from adapting gracefully.

**Fix**
Wrapped the field inside a `<group>` element with class `oe_subtotal_footer px-4` to ensure it inherits consistent padding and alignment with other form elements. This provides a flexible layout that handles longer text and browser zoom correctly, maintaining readability and visual consistency.

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

Forward-Port-Of: odoo/odoo#213012
Forward-Port-Of: odoo/odoo#211100

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.

Steps to reproduce:
- Create a product P1 with a BoM that includes:
  - Component 1 (sequence = 1)
  - Component 2 - KIT (sequence = 2), which itself contains:
      - Component 2-1 (sequence = 1)
      - Component 2-2 (sequence = 2)
  - Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.

Observed behavior:
- The generated stock moves are ordered as:
    1. Component 1
    2. Component 3
    3. Component 2-1
    4. Component 2-2

Expected behavior:
- The stock moves should respect the BoM line sequence:
    1. Component 1
    2. Component 2-1
    3. Component 2-2
    4. Component 3

Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430

Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.

opw-4809095

Forward-Port-Of: odoo/enterprise#87003

Current behavior before commit:

When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction.

Root Cause:

The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises
a lock error based on the permanent date. Additionally, the hard lock date (which overrides all other lock types and doesnt allow exceptions) and parent company lock date are ignored.

Fix:

Replaced the direct lock date check with _get_lock_date_violations(), which:

- Correctly considers user-specific temporary lock date exceptions.

- Returns violations based on effective lock rules (including hard lock).

- Provides a more generic error message.

Steps to reproduce:

- Use a tax report with carryover values (e.g. Belgian VAT return, line 81).

- Post a refund using a tax that maps to the carryover (e.g. 21% M).

- Generate a closing entry.

- Set the company’s tax_lock_date to a date covering the refund.

- Grant a temporary lock date exception to the user, covering the same date.

- Try to reset the closing entry → Lock date error is raised (incorrectly).

opw-4715100

Forward-Port-Of: odoo/enterprise#85337

Currently, an error is produced when the payslip start date is not set, but the end date is provided.

**Steps to reproduce:**
- Install `hr_payroll` module(with demo).
- Create new **Payslip** for employee **Anita Oliver**.
- Clear both the start and end dates under the "Period" section.
- Set only the end date.

**Error:**
`TypeError: '<' not supported between instances of 'bool' and 'datetime.date'`

**Cause:**
The `_compute_warning_message` method performs a comparison between `slip.date_from` and `contract_id.date_start` without verifying if `date_from` is set. When `date_from` is `False`, the comparison `False < datetime.date(...)` - [1], raises a `TypeError`.

[1] - https://github.com/odoo/enterprise/blob/a65314702b99df97c778d4f12f943191a19dafd1/hr_payroll/models/hr_payslip.py#L1029-L1031

This commit adds checks to ensure that start and end date is defined before performing date comparisons in warning message computation, preventing the error.

Sentry - 6618275041

Forward-Port-Of: odoo/enterprise#86091