**Steps to reproduce:**
1. Install l10n_es_edi_verifactu.
2. Switch to a ES company.
3. Create a customer invoice and send it to VeriFactu.
4. Enable Developer Mode.
5. Go to Settings > Technical > Sequences & Identifiers > Sequences.
6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it.
7. Set a prefix or suffix using any alphabetical character.
8. Create a new invoice and send it to VeriFactu

**Issue:**
Traceback on sending Veri*Factu:
`ValueError: invalid literal for int() with base 10: 'F260001'`

**Cause:**
The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail.

**Fix:**
Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration.

**opw-6037528**

Forward-Port-Of: odoo/odoo#255473

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

Forward-Port-Of: odoo/odoo#263742

Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item.

## Steps to produce:
- Install Manufacturing and Accounting
- Go to settings and Enable Analytic Accounting
- Search Analytic items and create a new Analytic Item by providing a description and amount.
- Gear Icon > print and open the WIP report

## Observed Behavior:
The report displays a product (laptop) with a demo reference.

This becomes problematic when an analytic item is tracked only with a project, as it still causes product and reference data to appear on the analytic item. This can mislead the user.

## Root cause:
After this [commit](https://github.com/odoo/odoo/commit/967ac550e38bab915180647dea6eccb2ae1b3b31), demo data values were added to the report to support report editor previews in the web studio. This helps users understand how the report will look while they are editing it.

However, although an account analytic line is defined at [1], no values for fields such as products and references are specified on the form. As a result, the template falls back to the preview values provided.

[1]-
https://github.com/odoo/odoo/blob/d66bb0d7b550b11876dbc7b9d87f5b2adc17dd74/addons/mrp_account/report/report_mrp_templates.xml#L32-L53

## Solution:
Using `data-oe-demo` instead of removing the fallback data appears to be the best approach, as it allows the report editor to continue using demo values for the report preview, as shown at [2]

**Before:**
<img width="871" height="340" alt="image" src="https://github.com/user-attachments/assets/91897dbd-65d8-4f70-8f22-ea38b42ba28d" />
**After:**
<img width="815" height="380" alt="image" src="https://github.com/user-attachments/assets/ffcf509b-f534-47a8-be1d-53a798995443" />

[2]:
https://github.com/odoo/enterprise/blob/a739c6c03c6629bad80f3fe61b1035ce156d59c6/web_studio/static/src/client_action/report_editor/report_iframe.scss#L65-L75

opw-6151563

Forward-Port-Of: odoo/odoo#262517

Steps to produce:
---
- Install the `Accounting` module.
- Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid).
- Log in as the portal user.
- Navigate to the invoices list and attempt to sort by **Status**.

Issue:-
---
- Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering.

Root cause:
---
- At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state.

Fix:
---
- Update the sorting configuration to use payment_state instead of state,
  ensuring that invoices are sorted correctly according to their payment
  status on the portal.

[1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52

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

Forward-Port-Of: odoo/odoo#262976

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop.

calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context.

https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19

duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field.

Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration.

Steps to reproduce:
1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00)
2. In the quick-create popover, change the end time to 14:00
3. Click "More Options"
4. Check the Duration field in the full form

=> Duration shows the original drag value (02:00) instead of 04:00

opw-6087449

Forward-Port-Of: odoo/odoo#257294

Steps to reproduce
1. Create a company with Egypt localization, currency EGP
2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts
3. Register a customer payment so the journal dashboard shows the Payments row with a negative amount
4. Switch the user language to Arabic
5. Open the Accounting dashboard

Issue
The Payments amount renders as "LE 5,000.00-" instead of "-5,000.00 LE". formatCurrency returns the string "-5,000.00 LE". In an Arabic page the leading "-" has no intrinsic direction, so the browser attaches it to the surrounding right-to-left Arabic text and visually moves it past the symbol. Sibling rows on the same dashboard render correctly because they already wrap the amount in dir="ltr", see
https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/views/account_journal_dashboard_view.xml#L252

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

Forward-Port-Of: odoo/odoo#266742