## Issue:
In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO
But if the MO is "locked" because a quality check has been performed, a Error is raised:
```
Odoo Warning
You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed.
```

## Steps to reproduce:
- Create a product tracked by quantity
- Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point)
- Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1)
- Click on Order
- Open the created MO and the Shop Floor (Remove the filters to see the WO)
- Complete the Quality Point
- Modify the Reordering Rule (Min/Max: 2)
- Click on Order - the error should be raised

## Cause:
The MO to update is retrieved here:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57
Using a domain defined in this function:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153

In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state
This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked

In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter
The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor
because this commit ensures that clicking a card starts the timer and changes the state to `progress`:
https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561
However, it could still theoretically be triggered under specific conditions

In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679)
ensures the MO is detected as different, so a new one is always created

opw-5012588
Odoo: https://github.com/odoo/odoo/pull/238537

**Steps to reproduce:**
- Install `Data Cleaning` app
- Activate notification in Odoo in the admin user profile
- Create a few duplicate contacts
- Go the the "Data Merge: Find Duplicate Records" scheduled action
- Run the action manually
- You should see new notifications telling you that they found potential duplicates
- In the top right MessaginMenu click on the notification, it opens a chatter
- Try to send a message in the chat window
- Traceback : `AttributeError: 'data_merge.model' object has no attribute '_get_thread_with_access'`

**Issue:**
The model doesn't inherit `mail.thread` so it uses `self.env['mail.thread']` directly to send notification:
```
self.env['mail.thread'].sudo().message_notify(
    ...
    model=self._name,
    notify_author=True,
    partner_ids=partner_ids,
    res_id=self.id,
)
```
But when sending the information with the `model` and `res_id` parameters the newly created `Store` uses `self.add("mail.thread", {"id": data.id, "model": data._name, **values})` and the message is assigned to a non-existing thread in the frontend.

**Fix:**
Explicitly check if the message is a `user_notification` and redirect the user to the discuss inbox if it's the case by reapplyng part of https://github.com/odoo/odoo/commit/b3be992c57dc5e412a127d05fc50b059814523aa

opw-5101510

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

Functional impact:

The main blog view (/blog) becomes very slow on databases with a high number of posts, tags and multiple blogs, when the sidebar option “Tags List” is enabled.
In large installations (thousands of posts and dozens of tags shared across several blogs), server response time can exceed 5–7 seconds, significantly affecting the user experience.

Steps to reproduce:

- Install website_blog.
- Create several blogs (3–4).
- Create a large number of posts per blog (1000+ total).
- Create many tags (40–60), shared between different blogs.
- Ensure many posts share multiple tags.
- Enable the “Tags List” option in the blog sidebar. -Access /blog without selecting a specific blog.

Current behavior:

The /blog page always calls: blogs.all_tags(join=True) when no blog is selected (blog=None). This triggers a heavy SQL aggregation query on: blog_post_blog_tag_rel and blog_post, even though when no blog is selected, the sidebar only needs the global list of tags, not per-blog aggregated information.
With large datasets, this query is expensive and may take several seconds. Because the sidebar requires all_tags, this query is executed on every request to /blog, even when no specific blog is chosen. The result is a TTFB of 5–7 seconds in real installations with high content volume.

Expected behavior:

When no blog is selected (blog=None), the /blog view should not execute heavy aggregation queries that depend on the size of the post–tag M2M relationship.
In this case, it is sufficient to load the global tags (blog.tag), because the sidebar widget does not require per-blog statistics. The main blog page should load almost instantly (<200 ms backend time), even on large databases.

Technical solution:

Adjust the logic so that when no blog is selected, the tag list is retrieved directly from blog.tag, avoiding the expensive SQL aggregation. Completely skip the heavy query when blog=None.
Preserve the original behavior when a specific blog is selected. The sidebar still works exactly the same and displays the same tags. No functional behavior changes and no data is lost.

Additional notes:

The slow TTFB (5–7 s) appears only in installations with:
- a large number of posts (thousands),
- tags shared across several blogs,
- the sidebar “Tags List” enabled. Small installations do not show the issue, which is why it can remain unnoticed, but it becomes critical in real production systems.

@Tecnativa TT59484


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