BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#100539
Forward-Port-Of: odoo/enterprise#95111

Currently, an error is produced when configuring the **Accounting Period** on the "**Tax Returns**" journal.

Steps to Reproduce:
1. Install `accountant` module without demo data using `-i` command.
2. Accounting > Dashboard > "**Tax Returns**" Journal, click on “Tax Returns” button.
3. Set an _Opening Date_ in the wizard and try to apply the **Accounting Periods**.

**Error:**
`ValueError - Expected singleton: onboarding.progress()`

**Cause:**
**Until saas-18.2,** 
The onboarding record’s `current_progress_id` was created by method `_search_or_create_progress()` - ([1]) during module initialization. This method was triggered through `_initiate_account_onboardings()`, which was called in the `_accounting_post_init()` hook for all companies - ([2]).

**From saas-18.3,** 
`_accounting_post_init()` was modified to call `_initiate_account_onboardings()` only for companies having a `chart_template` - ([3]).

As a result, companies without a chart template never receive a default progress record, leaving `current_progress_id` unset. When rendering onboarding values, this leads to a singleton error.

**Fix:**
This commit ensures that a progress record exists by creating it when missing before rendering onboarding values.

[1]:  https://github.com/odoo/odoo/blob/b2558e92e627a0efd975a402b77a6b53810c4c41/addons/onboarding/models/onboarding_onboarding.py#L107-L111
[2]: https://github.com/odoo/enterprise/blob/2f2b53f1c6f31ae22351d22cf4bf59ef01a63691/accountant/__init__.py#L22-L25
[3]: https://github.com/odoo/enterprise/blob/37dd63580967c1186618d7340a21539a6c98dbba/accountant/__init__.py#L22-L24

sentry-7064593163

When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled):
- the ANZ BIS3 Invoice & CreditNote that is deprecated in favor of the PINT version,
- the SG BIS3 Invoice & CreditNote that will also be deprecated soon by its PINT version.

Note that anyway for the moment we don't allow to register user from AU/NZ/SG on Peppol, so we were in any case registering those services for all participants, and none of them were relevant for those two local formats ...

In the future we would like to handle the received services(formats) on IAP directly to handle change better.

https://github.com/odoo/odoo/blob/0af9d32e305c1f1afb51e126c1e6747879e78225/addons/account/models/company.py#L35-L50

I checked on our AP, and only 8-10 invoices were sent with these formats, between Belgians... so it is most likely errors. Let's reduce the confusion.

<img width="1283" height="65" alt="image" src="https://github.com/user-attachments/assets/208bbd7e-f836-4bc9-a594-795313b06be9" />

Source: https://docs.peppol.eu/edelivery/codelists/v9.4/Peppol%20Code%20Lists%20-%20Document%20types%20v9.4.json

Forward-Port-Of: odoo/odoo#238674

*=website

Steps to Reproduce :
 1. Go to `edit` mode.
 2. Drop at least four block snippets.
 3. Drop a badge in the header next to the _Contact Us_ button.
 4. Undo twice → the _Badge_ reappears.
 5. Undo twice more → the _Badge_ reappears again.
 6. Redo three times → the _Contact Us_ button is duplicated.

Issue:
The `Contact Us` button in the header was duplicated after multiple undo/redo actions. Moreover, the `Badge` snippet did not behave as expected during undo/redo.

Reason:
When the uncommitted draft was cleared before undo/redo, the `OdooEditor` observer triggered the `OdooField` observer to roll back and flush mutations. However, this rollback was considered a new mutation by the `OdooEditor` observer. On the next undo, the `OdooField` observer tried to sync with these artificial mutations, causing duplication of buttons and badges.

Fix:
Deactivate the `OdooEditor` observer during undo/redo operations to prevent recording unnecessary mutations. After discarding the draft, reactivate the `OdooEditor` observer. This avoids redundant syncs and resolves the duplication issue.

task-4558376

Forward-Port-Of: odoo/odoo#233002
Forward-Port-Of: odoo/odoo#223579

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

Forward-Port-Of: odoo/odoo#238563
Forward-Port-Of: odoo/odoo#234737

Problem:
When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs.

Cause:
After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247
and then call `getFonts()`, which internally uses
`this.dependencies.split.splitAroundUntil()`.

If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws:
`The offset x is larger than the node's length (y).`

Solution:
After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid.

Steps to reproduce:
It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`.
A test case replicating the situation can be based on the original failing template in the customer’s database.

opw-4953943

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

Forward-Port-Of: odoo/odoo#234328