[FIX] mrp_workorder_plm: avoid singleton traceback when matching BOM operations
**Issue**
Adding a step in a manufacturing order with two operations that are too similar
could lead to a traceback when proposing an improvement from the Shop Floor.

**Steps to reproduce**
- Install the Product Lifecycle Management app.
- Create a BOM for any product with two operations that:
	- Have the same name and work center
	- Have no variant
- Create and confirm a Manufacturing Order for that product.
- Open the Shop Floor view.
- Click the gear icon -> Update Instructions -> Improvement Suggestion -> Add a Step -> Propose a Change.
-> A traceback occurs

**Cause**
When adding a step:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L10
It tries to find the corresponding operation in the ECO's new BoM.
This relies on `_get_sync_values()`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_plm/models/mrp_routing.py#L9-L13
Because two operations share the same name, work center, and no variant, both match the filter:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L39
This results in a singleton error when accessing `operation.id`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L42

opw-6241880

The following use case has been observed:

0. Customer start a payment from /shop/payment.
1. We received the webhook that notifies that the payment succeeded.
2. The payment post-processing cron start (it gather all the transactions that need to be processed, including the customer new transaction)
3. Meanwhile, the customer is redirected back by the payment provider to Odoo, which then redirect to /payment/status and start the payment post-processing for that specific transaction
4. The customer initiated payment processing finishes, he is redirected back to /my/orders/... page.
5. The payment post-processing cron finally start processing the same customer transaction and process it (a second time).

In that case, as the transactions to be post-processed backlog was quite high, there is consequent time between the time we gather all the TXs to post-process and actually process the customer transaction.

Also we don't end up with a `SerializationError` as the cron do commit after each transaction post-processing.

This commit force invalidate individual transaction cache values and recheck if it effectively still need to be post-processed before doing it.

opw-6332192

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

Forward-Port-Of: odoo/odoo#274010

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates, in the template, whether the real messages are rendered. That mirroring effect both read `mountedAndLoaded` as one of its dependencies and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write `[isLoaded=true, mountedAndLoaded=false]` pair; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window it drives `mountedAndLoaded` back to false while `isLoaded` stays true, and the settling patch then computes the very `[true, false]` pair already recorded. The effect never re-runs, so `mountedAndLoaded` is stranded at false and no message is rendered.

Depend on a monotonic `resetCount` instead. Reading it in the effect dependency array subscribes the render to it (OWL subscribes a `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: while loading, `applyScroll` resets on every patch, so an unconditional bump would spin the render loop; the guard re-arms only in the case that heals. `reset()` still clears `mountedAndLoaded` (the false dip is needed for the reload scroll handshake), so behaviour is otherwise unchanged.

The race is not deterministically reproducible with this version's test tooling, which cannot advance the render loop a single frame, so no test is added here; the fix is covered by tests on later versions.

https://runbot.odoo.com/odoo/error/940032

Forward-Port-Of: odoo/odoo#274059

Steps To Reproduce
------------------
1- Create a product (Goods):
- Select track inventory in General Information
- Go to inventory and set Routes to Replenish on Order (MTO)

2- Create an Sales Order for 10 units of the product and confirm.
3- Deliver 5 on the first picking, validate, and create the backorder.
4- Print the delivery slip.

Issue
-----
1- MTO: Ordered = 5, Delivered = 5, Remaining = 5.
2- Normal product: Ordered = 10, Delivered = 5, Remaining = 5.
The ordered quantity for MTO products is wrong, it shows the delivered amount instead of the original order total.

Cause
-----
The delivery report calculates the "Ordered" quantity by adding what we just delivered to what is left in the backorders. I found that the code was looking for move lines in the backorders to count what is left. When I checked a backorder that is waiting for stock (like MTO), there is no reserved stock yet, so no move lines exist. Because of this, the report thought the backorder was empty and ignored the remaining quantity.

Fix
---
I changed the calculation of `qty_ordered` to correctly handle split moves and unreserved backorders.
1. In the main loop, `qty_ordered` is now the sum of the done quantity and the demand of any linked backorders. This correctly reconstructs the total order for split moves and MTO scenarios by using `move_ids` to include unreserved moves.
2. In the secondary loop for empty moves, I added a check to skip backorders if they were already counted in the main loop. This avoids double-counting while still catching any items that were missed by the main loop.

opw-5112467


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

When an orderpoint fails during a portal user's transaction (e.g., eCommerce checkout), the system catches the `Procurement Exception` and logs a warning activity on the product template. The exception handler uses `.sudo().activity_schedule()`, which bypasses the write access restriction but leaves `env.uid` as the portal user.

Therefore, the restricted portal user permanently becomes the `create_uid` (Author) of the activity.

System exception activities should always be authored by the system (OdooBot), never by a portal or public user. This context leak corrupts the activity metadata by injecting an external user ID into internal backend logs. Chain `.with_user(SUPERUSER_ID)` to the `.sudo()` call in `stock_orderpoint.py` when scheduling the exception activity.

This ensures the environment context is stable and the activity is authored by OdooBot, which transcends multi-company record rules.

Steps to Reproduce on Runbot/Fresh Database on version 17.0:
1. Enable Multi-Company with Company A and Company B. Set Company B as the active company for the website.
2. Restrict the main Admin (Runbot) user strictly to Company A.
3. Create a Shared Product (Company field left blank).
4. Set a Reordering Rule (Orderpoint) for the product that is guaranteed to fail routing.
5. Navigate to the frontend website and sign up as a new user (this creates a Portal User in Company B).
6. As the newly signed-up Portal User, complete an eCommerce checkout for the shared product.
7. The checkout succeeds, but the backend triggers the orderpoint failure and logs the exception activity on the product template.
8. Check the chatter for this product: the `create_uid` is incorrectly set to the Portal User instead of OdooBot (1).
9. (In 19.0 Upgrade) Log in as the Admin user (set strictly to view Company A), navigate to the product, and the AccessError for reading will appear due to this leaked id.

[opw-6253978](https://www.odoo.com/odoo/my-support-tasks/6253978?debug=assets)


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

Forward-Port-Of: odoo/odoo#269395