Currently, a typo appears in the `Pending Message` shown in the 
SEPA Direct Debit payment provider configuration.

**Steps to reproduce:**
- Install the `payment_sepa_direct_debit` module.
- Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit.
- Open the `Messages` tab and observe the `Pending Message`.

**Observation:**
The message uses "an unique" instead of the grammatically correct "a unique".

**Fix:**
This commit corrects the message by replacing "an" with "a" at [1].

Before:
<img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" />

After:
<img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" />

[1]:
https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13

opw-5373274

Forward-Port-Of: odoo/enterprise#100983

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

## 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

**Steps to reproduce:**
* Install the **Accounting** module.
* Go to **Accounting > Configuration > Settings**.
* Download the **Import Journal Items** template.
* Keep the default journal codes in the template (e.g. *MISC*, *SAL*, *BNK*).
* Import the file containing these existing journal codes into it by **Accounting > Configuration > Settings > Initial Setup > Import > Import Journal Items > Upload data file**.

**Observed behavior:**
* Existing journals have their names overwritten by the values provided in the import file.
* For example, a journal with code **MISC** and name *Miscellaneous Operations* is updated to name **MISC** after import.

**Cause:**
* Journals are looked up by their `code`, but `_load_records()` passes both `name` and `id` for all rows.
* As a result, existing journals are updated instead of preserved.

**Fix:**
* Pass only `id` for journals already found by code.
* Pass `name` only when creating new journals.
* This prevents unintended updates to existing journal names.

opw-5345876

The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:
https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed.

#### Fix:

Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks.

#### runbot-226734

Forward-Port-Of: odoo/enterprise#100746

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