**Steps to reproduce:**
* Install the **Accounting** module.
* Unhide the **Start Date** and **End Date** fields on invoice lines.
* Create and post a customer invoice with deferred dates.
* Go to **Accounting → Reports → Deferred Revenue Report**.
* Add an annotation to a deferred revenue line by clicking the **annotate** from three dots next to the account.
* Export the report in **XLSX** format.

**Observed behavior:**
* The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value`

**Cause:**
* The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level.
* The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned.
* When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`.

**Fix:**
* Introduce a boolean flag `annotations_header_written = False` before the header loop to explicitly track whether the "Annotations" column header has already been written.
* Inside the header loop, set `annotations_header_written = True` after writing the header.
* After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_header_written` is still `False`, assign `annotations_x_offset` from the current `x_offset` and write the "Annotations" header.

opw-6354473

## Problem

When rendering PDF invoices that contain **section** or **note** lines, the `l10n_gcc_invoice.arabic_english_invoice` QWeb template raises:

```
TypeError: argument of type 'bool' is not iterable
```

This happens because `account.move.line` records of type `line_section` or `line_note` have `name = False`. The template evaluates `arabic_name not in line.name` (and the same for `english_name`), which fails because Python cannot apply the `in` operator on a boolean value.

## Fix

Add a `line.name and` guard before each `not in` check:

```xml
<!-- Before -->
<span t-if="arabic_name not in line.name" .../>
<span t-if="(english_name != arabic_name) and (english_name not in line.name)" .../>

<!-- After -->
<span t-if="line.name and arabic_name not in line.name" .../>
<span t-if="line.name and (english_name != arabic_name) and (english_name not in line.name)" .../>
```

## Steps to reproduce

1. Install `l10n_gcc_invoice` on an Odoo 16.0 instance.
2. Create a customer invoice and add a **Section** line.
3. Print/preview the invoice PDF.
4. Observe `Internal Server Error` / `TypeError: argument of type 'bool' is not iterable`.

Forward-Port-Of: odoo/odoo#267447
Forward-Port-Of: odoo/odoo#267147

Steps to Reproduce:
- Go to Settings → Technical → Sequences & Identifiers → Sequences.
- Open the sale.order sequence and note the current Next Number.
- Go to Sales → Quotations → Import (via the list view import action).
- Upload a .xlsx or .csv file with quotation/order data.
- Click Test (without clicking Import).
- Go back to the sequence configuration and check Next Number again.
- Repeat click Test again two or three times.
- Next number is increasing.

Issue:
Each click of Test advances the sale.order sequence's Next Number, even though no record is actually created or kept. After a few Test clicks, the sequence has skipped several numbers before a single real order has been imported — leaving permanent gaps in order numbering (e.g. SO0010, SO0011 skipped, next real order becomes SO0012).

Cause:
Test runs the import inside a database savepoint that is rolled back afterward (dry run). That create() call on sale.order still triggers ir.sequence.next_by_code(), which for standard-implementation sequences calls PostgreSQL's nextval(). nextval() is explicitly non-transactional in PostgreSQL — it is never undone by a rollback, even inside a savepoint — so the number is permanently consumed regardless of how many times Test is clicked or whether Import is ever pressed.

FIX:
Add a dry_run context flag, set when the import wizard is in Test mode, and check it in ir.sequence._next_do() to preview the next value instead of drawing a real one.

https://github.com/odoo/odoo/issues/241837

When an incoming email has a `.eml` file attached, the body of the attached email is used as the body of the message. Records created from the alias (Helpdesk tickets, leads, tasks, ...) end up with the wrong content in their description.

### Steps to reproduce

1. Send an email with body "Some nice content" and a `.eml` file attached to a Helpdesk alias.
2. Open the new ticket: the description shows the content of the `.eml`, not "Some nice content".

### Cause

`MailThread._message_parse_extract_payload` goes through every part of the email with `email.Message.walk()` and decides if each part is body text or an attachment.

The `.eml` file arrives as a part of type `message/rfc822`. The method sees the filename and adds it to the attachments. But a `message/rfc822` part is itself a full email, so `walk()` keeps going and also returns the parts inside it. These inner parts have no filename, so the method treats them as body parts of the outer message and end up replacing the real body with the content of the attached email. The inner text/plain part is also kept as an extra anonymous "attachment" file alongside the real `.eml`.

Conceptually, an attached email is opaque content, just like an attached PDF or ZIP. It is not a sub-tree of the outer email's parts. The parser should treat it the same way it treats any other attachment: read its bytes, store them, and not look inside.

### Fix

Replace `walk()` with a small iterator that walks multipart containers but stops at `message/rfc822` boundaries. The `.eml` is still captured as an attachment, but its inner parts are no longer visited, so the body is no longer overwritten and no anonymous "attachment" file is produced.

opw-6089248

# Introduction
This PR fixes broken mention links linked to the fact that we replace strings
without paying attention to the fact that some strings may contain others
that we want to replace later. This affects both id's and names of records.
See commit messages for more details.

# How to reproduce
- Create Contact A and then Contact B and either :
   - Contact B's id need to contain Contact A's id (e.g. Contact B id = 12; Contact A id = 1)
   - Contact B's name need to contain Contact A's name (e.g. Contact B name = ABC; Contact A name = AB)
- In a chatter create a message mentionning first Contact B and then Contact A
> Depending on the version, you might need to reload the page here

- Edit the message and save

# The issue
We see a broken mention in the chatter

# Cause
When saving an edited message, we give the raw body of the message (without the mention links) and the mentionend partners to `generateMentionsLinks` : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L152

This method's purpose is to replace the text links ("@Contact A") with actual html links. It does so by enumerating each partner given as an argument and replace the text mention with a placeholder :
https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L158

It will then replace the placeholders with actual links : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L208-L218

The issue is that in both of those steps, we can try to replace a string that is contained
in another string we want to replace. 

For exemple : 
"string123 some text string12"
If we try to replace "string12" first, then we will select the wrong string : 
"[string12]3 some text string12".

opw-6313748