### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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

Forward-Port-Of: odoo/odoo#264083

## Issue
When creating a job application with a new email address, a `res.partner` is created with both its name and email set to the email address, even if a `partner_name` is provided.

## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) and *Contacts* (`contacts`)
2. In Recruitment, create a job application:
    - Any Subject
    - Name N
    - Email E
3. Save the job application
4. Go to Contacts
5. **The partner created from the job application has both its name and email set to the Email E used to create the job application.**

## Cause
The `_inverse_partner_email` passes the email address to `find_or_create` to create the new res.partner:

https://github.com/odoo/odoo/blob/fc58ff23f491a2063b10ffcd6393a08b90dc7975/addons/hr_recruitment/models/hr_applicant.py#L317-L324

This method is implemented to parse both a name and an email address in the same string.

https://github.com/odoo/odoo/blob/fc58ff23f491a2063b10ffcd6393a08b90dc7975/odoo/addons/base/models/res_partner.py#L937-L945

We can thus provide both the `partner_name` and the `email_from` to the method to create a user with a name and an email address properly set.

## POS tests modifications
Before this first commit, some partners in `hr_recruitment` demo data were created with their email address as their name. This is the case, for example, for "Johan Duck", whose name was set to `coincoin@gmail.example.com`.

<img width="627" height="86" alt="260296" src="https://github.com/user-attachments/assets/e4bab843-8ba3-4930-af20-ca8603983929" />

In the POS tours, the list of loaded partners is limited to 100 partners and ordered by their order count (which is often null), __and their name__. 

https://github.com/odoo/odoo/blob/e7345340efbd66473da70ccf6680181b158047ce/addons/point_of_sale/models/pos_config.py#L845-L865

By "renaming" the partners from `hr_recruitment`, they started appearing higher up in the list because their name now starts with capital letters whereas their email began with lower letters, which are sorted after capital letters by the `ORDER BY` SQL clause. As a result, partners from multiple tours were pushed out of the 100 first partners, meaning they were no longer loaded during the tours, causing the tests to fail.

One solution, which is already used in other tests, is to give the test partners names that make them appear higher in the partner list, ensuring they remain within the first 100 loaded partners.



opw-6111598

Forward-Port-Of: odoo/odoo#260296

Steps to reproduce
1. Create a quotation
2. From the list view, select it and click Actions > Send an email
3. Pick the quotation template and send
4. The order stays in 'draft'

Issue
The Actions menu calls `action_quotation_send` with
`hide_default_template=True`:
https://github.com/odoo/odoo/blob/38734e4bc7d841a30524a2bc17fc94c9a83b5aa0/addons/sale/views/sale_order_views.xml#L1128-L1131
which skips the branch that sets `mark_so_as_sent` in context:
https://github.com/odoo/odoo/blob/38734e4bc7d841a30524a2bc17fc94c9a83b5aa0/addons/sale/models/sale_order.py#L1068-L1071

Without that flag, neither `message_post` (single order) nor the
mass-mail path (multi order) transitions the order to 'sent'. The
flag cannot be set unconditionally in `action_quotation_send` because
the same method also opens the composer for non-quotation emails
(e.g. `website_sale` cart recovery), which must stay in 'draft'.

Detect the quotation template at send time in `_action_send_mail`
and add `_message_mail_after_hook` for the mass-mail path.

opw-5248931

Steps to reproduce:
- Activate Anglo-Saxon accounting
- Create a product with track inventory and an automated inventory valuation product category
- Define MTO on the product
- Add this product to an Analytic Distribution Model (i.e. Legal)

- Create a SO for this product
- Create and confirm the PO related to it, the Analytic account is set on the PO.
- Confirm the reception of the product
- This creates a Stock valuation layer with the Analytic account
- Confirm the SO
- Confirm the delivery of the product
- This creates a Stock valuation layer with the Analytic account too
- Create the Invoice

Issue:
Missing analytic account on the 110300 Stock Interim (Delivered) creating unabalanced analytic accounting

Other:
test_report_invoice_items_anglo_saxon_automatic_valuation
introduced in this PR https://github.com/odoo/odoo/pull/205777
checks that in a project's analytic report, the values based
on cogs lines are displayed in the cost section.
With this fix, both cogs lines will have an analytic account
so their impact on the project analytic report will even out.
This made the test fail.
To keep the benefit of this test, we simulate that the user manually
removes the analytic account on some of the cogs lines
(those targetting stock interim received).


opw-6060567

1. Apply the below diff.
2. Login using the same account in two independent tabs (e.g. one regular tab, and a private one).
3. In the first tab, change the account password.
4. In the second tab, go to `/web/binary/upload_attachment` (any `type='http', auth='user'` controller would do) => 500 error.

> AttributeError: 'HttpDispatcher' object has no attribute 'env'

```
diff --git a/odoo/http.py b/odoo/http.py
index b0fd6197aea8..1ea817ec85cd 100644
--- a/odoo/http.py
+++ b/odoo/http.py
@@ -2309,7 +2309,7 @@ class HttpDispatcher(Dispatcher):
         """
         if isinstance(exc, SessionExpiredException):
             session = self.request.session
-            was_connected = session.uid is not None
+            was_connected = True
             session.logout(keep_db=True)
             response = self.request.redirect_query('/web/login', {'redirect': self.request.httprequest.full_path})
             if was_connected:
```

It is necessary to apply the diff because most places that raise `SessionExpiredException` also pro-actively `logout()`, i.e. they reset `session.uid` and when the exception reaches handle-error `was_connected` is always `False`. For the bug to occur, we need a way to be in the `was_connected == True` case but we found no way in standard Odoo (this also explains how this bug is still present, 2 years later). The diff is the easiest way we found to reproduce it.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

### Steps to reproduce:

- create a table (e.g. /table)
- type something in any cell and select that cell.
- apply formatting through toolbar (bold, italic, etc.)
- now select that single cell through mouse.
- observe that it is not selected

### Description of the issue/feature this PR addresses:

- The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected.

### Desired behavior after PR is merged:

- Cell selection was simplified using  areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected.

task-6207941

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

This is a backport of [commit](bf86b89f7cdab0ae378a1d897bfef625ccb4cb38).

#### Description of the issue:
A "childList" mutation record with multiple added or removed nodes is transformed and stored as a sequence of individual "add" or "remove" mutations.

Before this commit, each of the resulting "remove" mutations would contain the same previousSibling/nextSibling pair of the original record. The same happened for "add" mutations (in the form of the equivalent operation, e.g.  "append", "after", etc).

This was incorrect, as the previousSibling/nextSibling pair of the original record would not be the same for each added/removed node. Inserting nodes A and B between nodes P and N (previous and next siblings) is NOT equivalent to
[
    insert A between P and N,
    insert B between P and N // wrong,
]
The second resulting mutation does not make sense, as there's already a node A between P and N at this point, so it is ambiguous whether the insertion should should be done between P and A, or between A and N. So the correct equivalence, when converting a batch insertion of nodes A and B between P and N into a sequence of individual insertions, would be:
[
    insert A between P and N,
    insert B between A and N // correct
]

Similarly, when removing nodes A and B, having N an P as their outer siblings, the correct sequence of mutations would be: [
    remove A between P and B, // A's nextSibling is B at this point
    remove B between P and N
]

This incorrect information about siblings in stored mutations would lead, in some cases, to incorrect results when later applying or reverting mutations, as demonstrated by the test added by this commit.

Moreover, a mutation record having both added and removed nodes, when transformed into a sequence of individual mutations, should first contain the "remove" mutations, and then the "add" mutations, as the latter assumes that the original previous and next siblings, as references for inserting point, are siblings between each other, which is only true after the "remove" mutations took place.

task-4678910, 6205143

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

## Description of the issue/feature this PR addresses

The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section.  

This affects not only external modules but also internal ones that add menu items under *Contacts*.

## Current behavior before PR

When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy.

<img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" />

## Desired behavior after PR is merged

The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules.

<img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" />



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

Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence.

**Steps to Reproduce:(v-19.0)**
1. Install the `accountant` and `l10n_my_edi` modules (with demo data).
2. Switch to "MY Company"(Malaysian company).
3. Enable "_Quick Encoding_" for Customer Invoices in Settings.
4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice.
5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again.
6. Open the invoice list view and click **"Send to MyInvois"**.

**Error:**
`ValueError: not enough values to unpack (expected 4, got 2)`

The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1].

[1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146
Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263

sentry-7320998540