**Steps to reproduce:**
* Create a parent company with a branch company (Settings > Companies).
* Create a user whose **only** allowed company is the branch.
* While logged in as a parent-company admin, open the Miscellaneous Operations journal, find the first or second posted entry, reset it to draft, clear its name to a digits-only value (e.g. `0001`) and save – leaving it in draft state.  This stores `sequence_prefix = ''` and `sequence_number = 1` in the database.
* Log in as the branch-company user.
* Navigate to Accounting > Journal Entries > New.
* Set any date and save the draft entry (or simply write `name = '/'` on it).

**Observed behavior:**
* Saving fails with: `odoo.exceptions.AccessError: You are not allowed to access 'Journal Entry' (account.move) records.`

**Cause:**
* `_update_sequence_made_gap`, introduced in 19.0, detects sequence holes by running a raw SQL query that finds the two entries immediately before and after each move in the same journal with the same `sequence_prefix`. The query contains **no `company_id` filter**.

* In a branch-company setup the parent's journal (`journal_id`) is shared across companies.  When an early entry's `name` is cleared to a digits-only value its `sequence_prefix` becomes `''`.  A new entry created by the branch user also starts with `name = '/'`, which gives it `sequence_prefix = ''` and `sequence_number = 0`.  The SQL therefore returns the parent company's entry (`sequence_number = 1`, `sequence_prefix = ''`) as the `next_id` neighbour.

* The IDs from that query are passed to a local `browse()` closure, which in 19.0 read: https://github.com/odoo/odoo/blob/af37df9bee34fe60c1e51896af23fc7fe9b76cfc/addons/account/models/account_move.py#L5770-L5771

* `self.browse()` inherits the **non-sudo** environment of the branch user. When the method subsequently writes `move_n1.made_sequence_gap = …` on the browsed parent-company record, the ORM record-rule check finds the branch user has no access to that company → **`AccessError`**.

* This is a regression from 18.4 where the equivalent `_set_next_made_sequence_gap` explicitly used `.sudo()` when searching for neighbour moves: https://github.com/odoo/odoo/blob/22d84ae99bb79e7b1022367e6bc1b61cc8d9e8b1/addons/account/models/account_move.py#L5453-L5457

**Fix:**
* Add `.sudo()` inside the `browse()` closure so that neighbouring moves are always accessed with elevated rights, regardless of the calling user's company context.
* `made_sequence_gap` is a UI-only flag that indicates sequence holes; it carries no security or financial significance, making the sudo escalation safe.

opw-6231085

Forward-Port-Of: odoo/odoo#266676

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 reproduce:
-----------------------------------
1. Install the Field Service module with demo data
2. Go to Projects > Field service
3. Navigate to Calendar view
4. If there's no task in 'To Schedule' section, Drag and drop some tasks into it
5. Now, Try to drag and drop task from 'To Schedule' to the calendar

Observation:
-----------------------------------
The task is not scheduled by drag and drop in the calendar view

Issue:
------------------------------------
When a user drags a task, the Javascript Calendar Model creates an RPC call to
`plan_task_in_calendar(vals)`, where `vals` uses `planned_date_start` as the key
instead of the database column name `planned_date_begin`.
https://github.com/odoo/odoo/blob/153d6bab23f41f340058b98b7708ed058019f35c/addons/project/static/src/views/project_task_calendar/project_task_calendar_model.js#L44-L58

For standard project tasks, the backend `write()` method accepts
`planned_date_start` and triggers its `_inverse` method, effectively redirecting
the value to the deadline without complaining
https://github.com/odoo/enterprise/blob/2f8121157f6dd2e19e242cf8de93b321d7ae0415/project_enterprise/models/project_task.py#L412-L418

However, the `industry_fsm` module implements strict validation in its own
`write()` override: if it detects that dates were changed but
`planned_date_begin` is totally missing from the update values, it forcibly
resets all deadlines to `False`. Therefore, the FSM task scheduling was silently
aborted entirely.

https://github.com/odoo/enterprise/blob/2f8121157f6dd2e19e242cf8de93b321d7ae0415/industry_fsm/models/project_task.py#L169-L175

Solution:
------------------------------------
We override `plan_task_in_calendar` inside the `industry_fsm` module. This
cleanly resolves the mismatch between the frontend interface and the backend
table structure precisely at the RPC entry point. By isolating the fix mapping
strictly to the FSM module override, we ensure we satisfy the strict FSM
`write()` validations

Note
------------------------------------
Alternate Approach:
https://github.com/odoo/enterprise/commit/5cd627efdc3b2cf1db99a3532b36f2299b123724

Update the calendar view XML definition to use `planned_date_begin`
instead of `planned_date_start` for the `date_start` attribute.

As calendar drag-and-drop functionality fails due to field name mismatch.
The `scheduleEvent` method uses `fieldMapping` to construct vals with
'planned_date_start' as the `date_start` field.
https://github.com/odoo/odoo/blob/01df8267ec14cac4a773f78952a7aa9406e00fd4/addons/project/static/src/views/project_task_calendar/project_task_calendar_model.js#L44-L54

opw-6090448

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

**Steps to reproduce:**
* Install *Türkiye - Nilvera* (`l10n_tr_nilvera`) module.
* Log in as *admin user*.
* Create a *partner* for the company.
  * Set *country* as Turkey.
  * Configure required *taxes*.
* Create a *demo user*.
* Grant the demo user *Accounting admin access*.
* Log in with the *demo user*.
* Navigate to *Contacts* → open the *Turkey company partner*.
* Navigate to *Nilvera Status* (via Invoicing/Accounting tab) click on *Verify*.

**Observed behavior:**
* A *company access error* is raised during partner verification.

**Cause:**
* The field *l10n_tr_nilvera_api_key* is restricted with `groups='base.group_system'`, requiring full system admin rights.
* Users with *module-level admin access* (e.g., Accounting) do not have sufficient rights, causing the access error.

**Fix:**
* Use `sudo()` on `env.company` to bypass the restrictive group access.
* This allows users with appropriate *functional admin rights* to perform verification without granting full system privileges.

Ticket [link](https://www.odoo.com/odoo/project.task/6106907)
opw-6106907

Forward-Port-Of: odoo/odoo#262668

Problem:
When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed.

Cause:
When applying formatting, nodes matching
`is_formattable_node_predicates` are ignored. However, when checking
whether the selection is already formatted, those nodes are not ignored,
so the selection is erroneously considered to be only partially
formatted.

Solution:
Take `is_formattable_node_predicates` into account when checking whether a selection is formatted.

Steps to reproduce:
- Go to To-Do → Create New.
- Type some text and add inline code on the same line.
- Select all content using Ctrl + A.
- Apply formatting such as bold, italic, or underline using keyboard shortcuts (Ctrl + B / Ctrl + I / Ctrl + U).
- Press the same shortcut again to remove the formatting.
- Observe that the formatting is not removed.

task-6229228

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

Forward-Port-Of: odoo/odoo#267455
Forward-Port-Of: odoo/odoo#265183

Issue
-----
Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high.

Steps to reproduce
-----
- Setup Sendcloud delivery method
	- make it available in e-commerce
- Create a 150kg product and publish it
- Go to e-commerce
	- Add the product to cart
	- Checkout the cart

> Traceback

Cause
-----
We retrieve the order's weight through the context.

https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L108

If the call to `_get_shipping_rate` returns that the delivery requires multiple packages, we go into

https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L126-L128

If `order_weight` was not present in the context, this will cause an error in `sendcloud_convert_weight` since it expects a numerical value but receives the `None` fallback. This context key is only present when going through `choose.delivery.carrier` (so not in the e-commerce flow).

https://github.com/odoo/odoo/blob/058e640e6687ed3f709dc846f0fa7a1f45226849/addons/delivery/wizard/choose_delivery_carrier.py#L69

-----
Ticket:
opw-6210398

Forward-Port-Of: odoo/enterprise#117028

The Inventory Valuation report at a past date rebuilds historical value by tracing stock moves. Two product.value lookups run on the hot path and both hit unindexed columns:

- stock.move._get_manual_value() searches product.value by move_id for every traced move;
- product.product._get_last_product_value() searches product.value by product_id.

product.value declares neither column with an index, so each lookup performs a sequential scan of the whole table. This is harmless on small tables but degrades sharply as product.value grows (one row is written per manual standard-price/move revaluation).

On a database where product.value held ~9.6M rows, the per-move move_id lookup seq-scans the entire table only to return nothing (no row carries a move_id), repeated for every traced move, so the historical report never completes.

Index product_id (dense) and move_id (btree_not_null, since it is null for every manual revaluation row). Each lookup then becomes an index scan.

Measured on a ~9.6M-row product.value, historical valuation report, single date:

| product.value lookup        | without index             | with index         |
| --------------------------- | ------------------------- | ------------------ |
| by product_id (DISTINCT ON) | ~0.56s (1.7 GB seq scan)  | index scan         |
| by move_id, per traced move | full seq scan, returns 0  | index scan         |
| report (~3.1M moves traced) | never completes (>20 min) | completes (~3 min) |

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

Forward-Port-Of: odoo/odoo#266790

Importing attendees on an event that has an `after_sub` mail scheduler (the default on every event) fails with `savepoint "..." does not exist` and the import is aborted.

[`_update_mail_schedulers`](https://github.com/odoo/odoo/blob/b2f3270271f6/addons/event/models/event_registration.py#L298) runs the attendee scheduler synchronously on every registration create. The scheduler commits after each mail batch, which is fine from cron but problematic during an import: since [29460b723f49](https://github.com/odoo/odoo/commit/29460b723f49) [`load`](https://github.com/odoo/odoo/blob/b2f3270271f6/odoo/orm/models.py#L884) uses a single savepoint for the whole run, and any commit underneath releases it, so the next `ROLLBACK TO` / `RELEASE SAVEPOINT` raises `InvalidSavepointSpecification`.

When `import_file` is in context, trigger the cron like the async path already does so the mails are queued instead of running inline.

Steps to reproduce:

0. Have Contacts and Events installed
1. Events > Events, create a published event
2. Open the event, Attendees tab > Favorites > Import records
3. Upload a file with new attendees (Name, Email, no external id)
4. Click Import

=> "savepoint ... does not exist", import fails

Ticket [link](https://www.odoo.com/odoo/project.task/6124741)
opw-6124741

Forward-Port-Of: odoo/odoo#260648