Steps to reproduce:
- Install `l10n_dk` module
- Create the test branches under the `DK Company`
- Add both companies(parent and branch) in `Bank and Cash` account
- Go to Chart of Accounts and try to delete any account

Cause:
This error occurs because users can add multiple companies to a `Bank and Cash` account, although it should be prevented by the `_check_company_consistency` [constrain]. However, the code still allows it because, in this [commit], `depends_context=('uid',)` was set on the `company_ids` field to keep separate sudo/non-sudo caches for the field. As a result, during the validation [check], the user may still have stale cached values, causing the system to detect only a single company.

Solution:
Here, we first clear all cached values for the old record and force the ORM to re-fetch the values from the database, ensuring an updated recordset. So, the validation error is raised when saving multiple companies.

[constrain]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[check]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[commit]: https://github.com/odoo/odoo/pull/220294/changes/5096d083a38968425920aa5bf466b156eebb3dc7

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

Forward-Port-Of: odoo/odoo#263246
Forward-Port-Of: odoo/odoo#260261

With Employee Login enabled in POS, leaving the “Basic rights” field empty is meant to allow all employees to log in as basic cashiers.

In v19, configuring at least one Advanced/Minimal employee while keeping “Basic rights” empty incorrectly restricted the login list to only the explicitly configured employees (and the linked backend user), so other employees could no longer sign in.

Steps to reproduce:
-------------------
* Go to POS settings and enable Employee Login.
* Add at least one employee in Advanced rights.
* Leave Basic rights empty.
* Open POS login.

> Observation:
Only Advanced can sign in.
Other employees are missing.

Why the fix:
------------
The employee loading domain must only become restrictive when Basic rights is explicitly set. If Basic rights is empty, all company employees should remain selectable, and Advanced/Minimal should only affect roles, not visibility. Align with 19.1 behavior/state of code.

opw-6170066

Forward-Port-Of: odoo/odoo#263100
Forward-Port-Of: odoo/odoo#261939

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141

Commit 072a8e4fd061ff23902e6e448a577624cb27e188 fixes edition of buttons by wrapping the editable button in an editable span. But it allows user to write outside the savable node, and allows user to copy website builder's branding attributes (which causes issues when pasted).

This commit adds a span inside the button instead of outside, and removes it before saving the content.

Steps to reproduce:
- Open website buider on `/product/item-1`
- Place the cursor in the "Add to cart" button
- Press left arrow, repeat until out of the button
- Bug: You can write text there, but it won't be saved

#####
- Open website buider on `/product/item-1`
- Select some text in the "Add to cart" button
- Copy (`ctrl+c`)
- Paste (`ctrl+v`)
- Bug: Some content seems duplicated: the branding of the savable button has been duplicated inside it and the automatic replication between identical fields is based on this branding, thus replicates the button's content inside it

Similar issue about copy+pasted branding: ec93d48ab17b4a72f61fa358e5a81d2abcb18897

### Issue:
With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier
This makes no sense for internal moves

### Cause:
The method `_compute_l10n_ro_edi_stock_enable` was overridden to check for `not picking.batch_id`
However, for multi-step delivery routes, internal pickings still triggered the carrier validation, as no check on the `picking_type` was performed

### Steps to reproduce:
- Install `l10n_ro_edi_stock_batch` with demo data and switch to RO Company
- In Settings, enable `Multi-Step Routes`
- Set the RO Warehouse's Outgoing Shipments to `Pick then Deliver (2 steps)`
- Create a Product (e.g. RO product)
- Create a Delivery Method (e.g. RO Delivery, Partner: Any, Delivery Product: RO Product)
- Create and Confirm a Sale Order for the RO Product
- From the Sale Order, click Delivery and validate the picking 
### Before the fix, internal transfers raised:
`The picking RO Co/PICK/00001 is missing a delivery carrier.`

enterprise-PR: https://github.com/odoo/enterprise/pull/114166
opw-5925087

Forward-Port-Of: odoo/odoo#263036
Forward-Port-Of: odoo/odoo#257293

The session id rotates softly every 3 hours

For some features, the mobile app sometimes does requests "outside" of the mobile app, through a webview for instance, and if the session rotation interval is reached at that moment, it rotates the session and the `set-cookie`
instruction setting the new session cookie is received by the webview only, it's not propagated back to the mobile app.

Then, this could lead for the user to be logged out of the mobile app if the soft automatic session rotation happens at the very unfortunate moment the request through that webview happens.

For instance, the mobile app uses a webview to download attachments. If the session rotation happened during that request, the mobile app doesn't receive the `set-cookie` header and doesn't receive the new session id, leading for the user to be logged out of the mobile app.

This revision aims to provide an option for the mobile app to temporary skip the session rotation for a specific request, such as the requests done through the webview during downloads.

This option to be able to disable the rotation is not a security threat: If an attacker passes that header to disable the interval session rotation, he would avoid the session to be changed every 3 hours, but if he wouldn't he would still receive the new session id every 3 hours.
The session rotation is for legitimate user / computer to rotate their session every 3 hours so that in case of data leak of their browser cookies, there is a chance the session cookie is already no longer valid when published on the public web. Legitimate users have no benefit using this option header to disable the rotation.

Forward-Port-Of: odoo/odoo#263325

### Steps to reproduce:
- Download 'Sign' and 'Contacts' apps
- Create a contact with a really long name
- Create a sign document template with a multiline text field (Read-only) that has contact name value
- Click 'Sign Now' and put the new contact as the signer
- Sign and download
> The text appears as a single extended line exceeding field/page boundaries

### Cause of Issue:
The textarea and stamp field rendering only handled explicit newline characters (`\n`) and did not account for text that exceeded the field width. https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/sign/models/sign_document.py#L330-L345 When the HTML preview showed wrapped text, the PDF output rendered it as a single line. For continuous text without spaces, the text would overflow the field boundaries entirely.

### Fix:
Accounted for long texts that have spaces and long words to show all the information in the PDF

opw-6045062

Forward-Port-Of: odoo/enterprise#114813

**Steps to reproduce:**
Log in as admin and ensure notifications are handled in Odoo.
Enable push notifications and the 'Task Created' subtype for a project.
As a second user, create a new task in that project.

**Current behavior before PR:**
admin received escaped content in the push notification
(e.g., `A new task has been created in the "Project Name" project`)

**Cause:**
For inbox users, we send a client-side push notification using `previewText` as
the body. This field returns a markup object containing escaped characters,
which are converted to a string when passed to the notification body. Since the
notification body only accepts plain text, these characters are displayed
literally to the user.

**Desired behavior after PR is merged:**
admin receives the unescaped content in the push notification.
(e.g., `A new task has been created in the "Project Name" project`)

task-5112810

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

Forward-Port-Of: odoo/odoo#263187
Forward-Port-Of: odoo/odoo#240331

Steps to reproduce:

* Enable multiple languages
* Go to Sale Order Templates and create a new template
* Add a product line, then click the translate button on the description field
* A confusing validation error appears for missing `sale_order_template_id`

Issue:

* Instead of highlighting the missing required fields on the sale order template form view, it raises a misleading validation error on `sale_order_template_id`

Cause:

* `useTranslationDialog` always attempts to save the passed record directly. In O2M list views, the field can belong to a nested relational record, so the correct behavior is to save the root record instead.

Affected Version: 17.0

Before:
<img width="1919" height="1014" alt="image" src="https://github.com/user-attachments/assets/cd61381d-289a-4df4-bdf2-7881fa851939" />

After:
<img width="1920" height="887" alt="image" src="https://github.com/user-attachments/assets/5218c74b-c024-4994-b816-cb7ae69b420f" />

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

Forward-Port-Of: odoo/odoo#262988
Forward-Port-Of: odoo/odoo#262755

Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode interface without validating the picking, both serial numbers show up on the picking view. However, the first serial number’s `stock.move.line` was deleted, so only one serial number should be there. 

When exiting the barcode interface a call to `post_barcode_process` is made, where the extra `stock.move.line` is deleted, but it doesn’t wait for the call to finish. 
https://github.com/odoo/enterprise/blob/d5a52cb79c9c41d792685d2858cfeb6aee147642/stock_barcode/static/src/models/barcode_picking_model.js#L1896

Purpose: By overriding `beforeQuit` to add the `_onExit` call, the component now waits for the `post_barcode_process` call to finish before navigating back to the picking view. This helps ensure the UI displays the updated data. 

Steps to reproduce on Runbot:
Create a product tracked by serial numbers.
Have 2 units on hand: serial 001 with a package, and serial 002 without a package. (This is needed so the barcode app will create a new line).
Create a delivery for 1 unit of our test product and mark it as todo.
Ensure that serial 001 is reserved.
Click the Barcode smart button and scan the barcode for serial 002.
Click the back button.
Observe that both serial numbers are shown on the picking. 
Refresh the page and observe only serial 002 is now shown. 

opw-6105740

Forward-Port-Of: odoo/enterprise#115491

The employment subsidy calculation was incorrect in two main scenarios:

### 1. Incorrect threshold prorating:

The system was comparing the salary against the full monthly limit even for partial periods (weekly or bi-weekly). This resulted in employees wrongly receiving the subsidy when their proportional salary actually exceeded the limit.

Example: In 2026, the 14-day threshold should be 5,292.67 (11,492.66 / 30.4 * 14). Currently, an employee earning 10,000.00 in those 14 days still gets the subsidy because it's being compared against the full 11,492.66.

### 2. Cumulative monthly cap:

When multiple payslips occur in the same month, the total subsidy sometimes exceeds the statutory monthly maximum (536.22 for 2026) because the cap wasn't enforced across all slips.

Example: The 2026 maximum monthly subsidy is 536.22. In a month with three partial payslips:
- Mar 1st - Mar 14th: The system grants 246.68.
- Mar 15th - Mar 28th: The system grants 246.68.
- Mar 29th - Apr 11th: For the 3 days belonging to March, the system grants an additional 52.86.
Total subsidy for March reaches 546.22, exceeding the legal cap.

### Changes included in this PR:
- Updated `l10n_mx_rule_parameter_uma` to include monthly and annual values. This prevents rounding discrepancies.
  Example: the 2026 annual UMA published is 42,794.64. In a rule the calculation is: l10n_mx_uma * 30.4 * 12 = 117.31 * 30.4 * 12 = 42,794.68 resulting in a ~0.04 difference.

- Create a new rule parameter `l10n_mx_rule_parameter_subsidy_salary_limit` to have the subsidy eligible threshold. Starting in 2026, the government's rounding changed from zero decimals(e.g., 9,081.00 in 2024, 10,171.00 in 2025) to two decimals (11,492.66). Storing these as explicit parameters avoids the precision errors.

- Added comprehensive unit tests covering:
  - Complete periods: validates standard payslips aligned with the month calendar (bi-monthly, monthly, bi-weekly).
  - Overlapping periods: validates split-month scenarios (14-day, 10-day, weekly) where periods cross month boundaries:
    Example of self._overlapping_period("weekly", 7, 2646.33, (35.24, 88.10), (3, 123.34), (77.53, 35.24))
    This test covers 5 weekly payslips with the following subsidy
    distribution:
    - Tuple `first_payslip` => (35.24, 88.10) means that:
      First payslip (Apr 29 - May 5), the subsidy is 35.24 for April and 88.10 for May.
    - Tuple `mid_payslips` => (3, 123.34) means that:
      For the next 3 payslips fully in May, the subsidy is 123.34 each.
      Payslip 2 (May 6 - May 12): Subsidy for May = 123.34
      Payslip 3 (May 13 - May 19): Subsidy for May = 123.34
      Payslip 4 (May 20 - May 26): Subsidy for May = 123.34
    - Tuple `last_payslip` => (77.53, 35.24) means that:
      Last payslip (May 27 - June 2), the subsidy is 77.53 for May and 35.24 for June.
  - Across years: subsidy amounts and limits are updated annually.
    Therefore, if a period overlaps two years, a salary amount might be eligible for a subsidy in January but not in the previous December, and the paid subsidy is increased in January due to the new limits.

- Cleaned up redundant tests (test_regular_payslip_subsidy) and adjusted decimal precision.

- For split-month `schedule_pay` periods, the first payslip might generate a subsidy. However, in subsequent payslips, due to commissions or a wage increase, the employee may exceed the monthly subsidy salary limit.
  In those payslips, a warning is shown to notify the user that a manual adjustment is required.
  Created tests to validate these cases.

target: 19.0
task-5419659

Forward-Port-Of: odoo/enterprise#107601

Steps to reproduce
1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. Create a sale order for a storable subscription product and confirm it.
3. Open the generated delivery order and check its Scheduled Date.

Issue
The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value
(https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398).

The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`.

Solution
Split the two cases explicitly:
- First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow.
- Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722).

opw-6133831

Forward-Port-Of: odoo/enterprise#116362
Forward-Port-Of: odoo/enterprise#115100

### Issue before this commit:
The XML export for branch companies incorrectly identified the branch as the sender, even when a Peppol parent company was configured.

### Steps to reproduce the issue:
1. Download Accounting, Contacts and l10n_be
2. Create a branch for a Belgium company
3. Enable Peppol sending on the parent company
4. Enable Peppol sending on the branch company using the parent company endpoint
5. Switch to branch company
6. Create a customer invoice in the branch company using a customer who is on the Peppol network (meaning insert a valid VAT number and then verify button in the Accounting tab)
7. Confirm and send the invoice via Peppol
8. Download the resulting xml file and check the "AccountingSupplierParty" nodes. It contains the data of the branch and not the ones of the parent company

### Cause of the issue:
The EDI export logic was fetching the supplier data directly from the invoice's company record without checking for a delegated Peppol parent company, ignoring the hierarchical relationship defined in the settings.

### Reason to introduce the fix:
This fix ensures that the AccountingSupplierParty in the UBL/CII file correctly reflects the parent company's data when applicable.

opw-6030526

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

Forward-Port-Of: odoo/odoo#260389

**Problem:**
After importing records through the Import action, the list view that opens with the imported records does not inherit the context of the originating action. Column visibility and default values that depend on that context (e.g. `default_move_type` on the shared invoice list) end up wrong.

**Steps to reproduce:**
1. Go to Accounting → Customers → Invoices
2. Click "Favorites → Import records"
3. Upload a CSV containing at least one valid customer invoice row
4. Run the import and look at the "Imported records" list that opens

**Current behavior:**
The imported records list opens with an empty context. Columns rendered conditionally on `default_move_type` (invoice-type-specific columns on `account.view_invoice_tree`) are not shown as they are when opening the list from the menu, and records created from that list have no default move type.

**Expected behavior:**
The imported records list should open with the same context as the action the user started the import from (e.g.
`{ default_move_type: 'out_invoice' }` for customer invoices), so columns and defaults match the previous view.

**Cause of the issue:**
`openRecords()` in `import_action.js` builds the follow-up `ir.actions.act_window` but never forwards `this.model.context`. The model already holds the context passed through the import action's `params.context`, but it is dropped when the redirect action is dispatched, so the window action opens with an empty context.

**Fix:**
Forwarding the context the import was launched with keeps the user inside the same functional scope (invoice type, default partner, company, etc.) when they land on the imported records list. Column visibility logic and default values that rely on that context behave identically to opening the list through the normal menu flow.

opw-6120758

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

Forward-Port-Of: odoo/odoo#261309

#### Issue:
The budget report displays duplicate analytic lines.

#### Steps to reproduce:
In a new company:
- Create a budget with one budget line (Analytic Account A).
- Create one analytic item (linked to Analytic Account A).
- Open the budget report and remove the default "open budget" filter.
Duplicate amounts appear in the pivot view and duplicate lines appear in the list view.

#### Cause:
In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report.

#### Fix:
Use three separate queries, each with specific filter conditions to guarantee unique results:
Q1 - Analytic lines with no matching budget line.
Q2 - Analytic lines matched to a budget line with no company (null-company).
Q3 - Analytic lines matched to a company-specific budget line.

OPW-6051696

Forward-Port-Of: odoo/enterprise#116612