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

When calling on a empty recordset action_mark_as_done, it creates a traceback.

**Observation**

When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 
Inside button_finish, it retrieves all open workorders and marks them as done:
 - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 
 - mark them as done:
https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678

Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 

-> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback.

opw-6239910

Forward-Port-Of: odoo/enterprise#118718
Forward-Port-Of: odoo/enterprise#118403

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

Steps to reproduce:
1- Install the Attendance app
2- Enable PIN Identification in setting
3- Go to Admin user (who is also an employee) and remove their admin access on the Employees field and save.

Issue:
`AccessError: You do not have enough rights to access the field "pin" on Employee (hr.employee).`

Expected behavior:
User can change their access rights without getting AccessError

Why this happens:
The addition of the Employee PIN to the Preferences tab in v19.0 (commit edc6562) causes this error. During web_save, a read is triggered for all fields in the view. Since the user just removed their own HR rights, they no longer have access to the PIN field. While the PIN was moved in v19.1 (commit a2e785b), it remains in v19.0.

Fix:
- Removing the field from the xml file was not enough as it introduced another error: 
- `AccessError: You do not have enough rights to access the field "version_id" on Employee (hr.employee).`
- Commit 5024fc7 changes field `work_location_id` to be editable. This field is related to an `hr.employee` field which depends on `version_id`. Saving now causes this field to be read through this chain, which causes an an implicit access.
- Set `related_sudo=True` to allow the user to read their own employee data during the save

Note:
This `version_id` error doesn't exist from v19.1 upwards due to the refactor made in commit 96050453.

opw-6112646

Forward-Port-Of: odoo/odoo#262053

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

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

Issue:
----------------------------------------
When searching for a field from `hr.version` without any rights on Employees, we get an access error.

Steps to reproduce:
----------------------------------------
- Timesheet > To Validate > All timesheet
- Filter on Employee > Department (is set for example)
- An error pops up

Cause:
----------------------------------------
The field `department_id` of `hr.employee` belongs to `hr.version` and is accessible through the `_inherits` and the field `version_id`. When doing the search above, during the optimization of the domain, we end up trying to read `department_id` on `hr.employee.version_id`. But the field `hr.employee.version_id` is not accessible to users without Employee access rights. They only have rights on the field  `hr.employee.current_version_id`.

This occurs from version saas-19.1 because the access check was added in this version. ([commit](https://github.com/odoo/odoo/commit/aa58663a271e24a1fcb3f59e6bddfac50054703c))

Solution:
----------------------------------------
We remove the group restriction on `version_id`. The group restrictions are done with the fields of `hr.version`. As `version_id` is only a computed field from `current_version_id` which has `bypass_search_access=True`, this should not expose any field that wasn't already. `bypass_search_access=True` was added on `current_version_id` for the same reason. ([src](https://github.com/odoo/odoo/commit/94bb4a29189400d6bd0c2ca97eba271601262e1b))

opw-6149198 
opw-6251866

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