Problem:
When duplicating a section containing sale order lines, the system should preserve any manually modified unit prices on those lines. However, the system would reset the unit price back to the product's default because the duplication process triggers a standard product onchange, which wipes the custom price on the new duplicated order line.

Solution:
Override onchange_batch on sale.order.line to intercept line initialization during a duplication. If a copied price_unit is present in the payload, the method restores that modified price and recalculates the subtotal and tax amounts accordingly, ensuring the duplicated line accurately reflects the original line's pricing.

Steps to reproduce(runbot v19):
1. Create a Quotation and add a product line under a section.
2. Manually modify the unit price on the product line to a custom value (e.g., set $10 to $99).
3. Click the section dropdown menu and click Duplicate.
4. Notice the duplicated product line incorrectly resets its unit price back to the default price ($10) instead of preserving the manually modified price ($99).

opw-6421922

## Description

Fixes issue #187539 where selecting text that extends outside the HTML editor boundaries throws an uncaught promise error.

## Problem

When using Ctrl+A or dragging a selection from inside the editor to outside its boundaries, the `updateSelectionTable` method in `table_plugin.js` would process the invalid selection and call `setSelection()` with nodes outside the editable area, causing:

```
UncaughtPromiseError: Selection is not in editor
```

This only affected Chromium-based browsers (Chrome, Edge) as Firefox already had protection against this scenario.

## Solution

Added a safety check in `updateSelectionTable` to verify that the document selection is within the editable area before processing table selection updates. This extends the same protection Firefox had to all browsers.

## Changes

- `addons/html_editor/static/src/main/table/table_plugin.js`: Added validation check
- `addons/html_editor/static/tests/table/selection.test.js`: Added regression test

## Testing

The new test verifies that selecting from inside a table to outside the editor does not throw an error.

Closes #187539

Validating payslips through the Payslips list view's "Validate" header button does not generate their PDF, nor does it queue them for the "Payroll: Generate pdfs" scheduled action to pick up later. The PDF only gets generated if the user separately clicks the "Confirm" button afterwards.

### Steps to reproduce:
- Install Payroll with demo data.
- Go to Payroll > Payslips > Pay Run, generate payslips for a few
   employees ("Regular Pay").
- Select one or more of those draft payslips in the list view, and click the
   "Validate" header button.
OR
- Run the "Payroll: Generate pdfs" scheduled action. 
- Open any affected payslip.

### Observed behavior:
No PDF attachment is ever created for the payslips validated this way, even after the cron runs.

### Expected behavior:
PDF attachment should be generated when validating the payslip, via "Validate" Button or cron

### Root cause:
[action_payslip_done()](https://github.com/odoo/enterprise/blob/7b309f2e74f9fa37b109375de6387db3241c2bcb/hr_payroll/models/hr_payslip.py#L607-L641) only runs its PDF-generation block when `self.env.context.get('payslip_generate_pdf')` is truthy. The Payslips list view's "Validate" button at [1] was missing
`context="{'payslip_generate_pdf': True}"`, unlike the "Confirm" button right next to it and the Pay Run's own "Validate" button, both of which already carry it. Without it, the whole PDF block is silently skipped: queued_for_pdf never gets set, so there is nothing for the cron to act on either.

[1]-
https://github.com/odoo/enterprise/blob/7b309f2e74f9fa37b109375de6387db3241c2bcb/hr_payroll/views/hr_payslip_views.xml#L10-L12

### FIX:
Add the missing context="{'payslip_generate_pdf': True}" to the "Validate" button in the Payslips list view header.

**opw-6401393**

## Description

Fixes issue #187539 where selecting text that extends outside the HTML editor boundaries throws an uncaught promise error.

## Problem

When using Ctrl+A or dragging a selection from inside the editor to outside its boundaries, the `updateSelectionTable` method in `table_plugin.js` would process the invalid selection and call `setSelection()` with nodes outside the editable area, causing:

```
UncaughtPromiseError: Selection is not in editor
```

This only affected Chromium-based browsers (Chrome, Edge) as Firefox already had protection against this scenario.

## Solution

Added a safety check in `updateSelectionTable` to verify that the document selection is within the editable area before processing table selection updates. This extends the same protection Firefox had to all browsers.

## Changes

- `addons/html_editor/static/src/main/table/table_plugin.js`: Added validation check
- `addons/html_editor/static/tests/table/selection.test.js`: Added regression test

## Testing

The new test verifies that selecting from inside a table to outside the editor does not throw an error.

Closes #187539

In `account.asset-sk.csv` the asset-account column has slipped by one row for the last two entries, so each of those two models pairs an asset account with the accumulated depreciation account of a different asset class.

As shipped (Slovak account names glossed in English):

    sk_asset_basic_herd_and_draft_animals
        asset         029000  Ostatný dlhodobý hmotný majetok   "Other tangible fixed assets"
        depreciation  086000  Oprávky k základnému stádu        "Accumulated depreciation, basic herd"

    sk_asset_other_tangible_fixes_assets
        asset         031000  Pozemky                           "LAND"
        depreciation  089000  Oprávky k ostatnému DHM           "Accumulated depreciation, other tangible"

Every other row in the file pairs an account with the accumulated depreciation account that names it: 012000 with 072000, 021000 Stavby ("Buildings") with 081000 Oprávky k stavbám ("Accumulated depreciation, buildings"), and so on. Only these two break the pattern, and both break it the same way.

`account.account-sk.csv`, in the same directory, disagrees with them and is right: it links 026000 Základné stádo a ťažné zvieratá ("Basic herd and draft animals") to the herd model and 029000 to the other-tangible one, and gives 031000 Pozemky no asset model at all, land not being depreciable under Slovak law or any other.

The consequence is not cosmetic.
`account.account.asset_model_ids` creates an asset when a vendor bill line hits the account, and the asset takes its accounts from the model. So on a Slovak database a bill booked to 029000 "Other tangible fixed assets" produces an asset whose value sits on 031000 "Land" and depreciates over six years, while the account that should have carried it never does.

Corrected to the accounts that both the accumulated depreciation side and `account.account-sk.csv` point at:

    sk_asset_basic_herd_and_draft_animals   asset 026000  Základné stádo a ťažné zvieratá  "Basic herd and draft animals"
    sk_asset_other_tangible_fixes_assets    asset 029000  Ostatný dlhodobý hmotný majetok  "Other tangible fixed assets"

Verified by loading the SK chart on a clean database: all ten asset models now pair with their own accumulated depreciation account, and none points at 031000.

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:
- Open a PoS so that the Opening Control popup is displayed.
- Cut the connection to the server without the browser going "offline" (e.g. the router stays up but the internet link is down).
- Click on "Open Register".
- Restore the connection, make some orders, close the session.

Issue:
The session is closed with orders but was never opened on the server: it has no opening date, keeps its temporary name "<config>/00000", and the opening cash was never recorded.

`set_opening_control` was called with the `queue` flag. On a ConnectionLostError the call was silently pushed to the in-memory unsync queue, and the popup marked the session as opened locally and closed itself. That queue is only replayed on the browser `online` event, which is never fired when the device stayed connected to its local network, and it is lost when the tab is closed or reloaded. Meanwhile the server accepts orders on a session in `opening_control`, and nothing checks it at closing.

Opening the register is not an operation that can be deferred: the session must be opened before any order is made. The call is no longer queued. When the connection is lost, the user is told that the register cannot be opened offline, and the popup stays open so the opening can be retried once the connection is back.

opw-6580262

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

Forward-Port-Of: odoo/odoo#288899

**Steps to reproduce:**
- Set preferences to dark mode
- Create a quotation and add a product with optional products (e.g customizable desk) -> Background of optional products is lighter than the surrounding div

**Behavior:**

The `div` showcasing optional products is set to be a bit darker to add contrast in the modal. In light mode, table's background is transparent, which allows it to adapt to a darker container. 
However, this is not the case in dark mode, which causes a mismatch between table and div backgrounds.

By default `$table-bg` follows `$body-bg`:
https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/lib/bootstrap/scss/_variables.scss#L738-L740 And is later set to transparent here:
https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/src/scss/bootstrap_overridden_frontend.scss#L74-L75

However when darkmode is enabled, `$body-bg` is re-assigned, which forces `$table-bg` back to the default dark color, bypassing the transparent override. https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/lib/bootstrap/scss/_root.scss#L132-L139

---

This commit ensures that `table-bg` is explicitly set to transparent for tables displaying optional products.

opw-6569713

Steps to reproduce:
- Import a product CSV with one row per attribute value ("Product Values" column) and an image URL on every row, or create several variants of the same template in one `create()` call with an image.
- Open the product: neither the template nor the variants have an image. Products without attribute values imported in the same file are fine.

The import creates all variants of a template in a single batch. The inverse of `image_1920` is applied record by record: the first variant finds no image on the template and writes its image there. Writing `image_1920` on the template invalidates the image cache of every product.product, including the sibling variants being created, whose `image_1920` is protected during the inverse and therefore reads back as empty. The next variant then takes the "clear the image from the template" branch and writes `False` on the template, undoing the first write. Nothing is stored.

Read the value to inverse for every record before writing anything, so the invalidation triggered by the template write cannot change what the following records write.

opw-6545651

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

Problem:
When a link's metadata contains whitespace-only strings for `og_title`, `og_description`, or `og_image` (e.g. `og_title: "   "`), the link popover displays an empty clickable preview area.

Cause:
`LinkPopover` assigned raw metadata values directly. Non-empty whitespace strings evaluate to truthy values in JavaScript (`"   "` is truthy), preventing fallback to the default URL or empty string.

Solution:
Trim the metadata values (`og_title`, `og_description`, `og_image`) when populating state so that whitespace-only values evaluate to empty strings and trigger appropriate fallbacks.

Steps to reproduce:
- Open HTML editor.
- Add a link with URL `https://netorg4182089.sharepoint.com/:v:/s/projects/IQD72ajP3WOBT4jcAu_1qLfIAamL9lvrq4ls1Bs9XCyXJvw?e=vQ9wH3`.
- Open the link popover. => Observe that the popover title falls back to the URL instead of showing an empty clickable space.

opw-6564118

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

Currently, an error occurs when a user opens the website and Live Chat is initialized with an invalid URL regex.

Steps to Reproduce:
 - Install `website_livechat` without demo data.
 - Open `Live Chat` and, in the `YourWebsite.com` channel, click the 
   `three-dot` menu and select `Configure Channel`.
 - Go to the `Rules` tab.
 - Add a rule, select `Welcome Bot` in `Chatbot`, and set an invalid regex such as 
   `*` in `URL Regex` and save.
- Click `Join Channel`.
- Open the `website`.

`re.PatternError: nothing to repeat at position 0
when serializing dict item 'result'
`
 - when `URL Regex is '['`

`re.error: unterminated character set at position 0 when serializing dict item 'result'`

When a user opens the website, Live Chat is initialized by checking operator availability and 
finding the matching country/URL rule [1]. The rule matching checks whether `regex_url` matches 
the current page URL. It uses `re.search()` [2], which compiles the regex pattern before searching. 
If `regex_url` contains an invalid pattern such as `*`, `re.search()` raises `nothing to repeat at position 0` 
because `*` must follow a preceding regex element. Similarly, `[` starts a character set (`[...]`) 
but has no closing `]`, causing `unterminated character set at position 0`.

This commit adds a constraint to validate `regex_url` and reject invalid regex patterns 
when creating or updating Live Chat rules.

[1]- https://github.com/odoo/odoo/blob/f962f1eccecfdbc95375f795174c8f687459b521/addons/im_livechat/controllers/main.py#L87

[2]- https://github.com/odoo/odoo/blob/f962f1eccecfdbc95375f795174c8f687459b521/addons/im_livechat/models/im_livechat_channel.py#L387

sentry-7679767396


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

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the CO Company.
- Disable `Test environment` and enable `DIAN Demo Mode` in the invoicing settings.
- Set a `Technical control key` on the `Customer Invoices` journal.
- Create and confirm an invoice with Terms and Conditions.
- Send the invoice to `DIAN`.
- Open the generated XML file and observe the `cbc:Note` tag.

**Observation:**
The `Note` tag contains the `technical control key`.

**Expected behavior:**
The `Note` tag should only contain the Terms and Conditions value
from the invoice. (Confirm with PO [1])

**Root Cause:**
At [2] and [3], the code includes the `technical key` in the `Note` tag.

[1]:
https://www.odoo.com/mail/message/1164671931

[2]:
https://github.com/odoo/enterprise/blob/a5f4bde1aa33ea7b796d7ee3f9d713a6c8ab8348/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L664

[3]:
https://github.com/odoo/enterprise/blob/a5f4bde1aa33ea7b796d7ee3f9d713a6c8ab8348/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1600-L1603

opw-6513843

Forward-Port-Of: odoo/enterprise#131495

Issue
=====
Currently, the Barcode app doesn't work very well when the user scans packaging and lots. If they want to apply one or multiple packagings to a specific lot, the quantity is not quite exact since scanning a lot already increases the quantity by 1.
Also, if there are multiple lots, the packaging quantity isn't added to the last scanned lot which is problematic.

How to reproduce
================
1. Active "Units of Measure & Packagings" and "Lots & Serial Numbers" settings;
2. Create a product tracked by lots with a barcode;
3. In the "Sales" tab, add a packagings (for example, "Pack of 6");
4. Configuration > Units & Packagings > Selected the added UoM > Click on "Packaging Barcodes";
5. Create a new barcode for the created product;
6. Create and confirm a receipt for 12 units of this product and open the operation in Barcode app;
7. Scan the product's barcode, then a lot then the packaging barcode -> First issue: the line has 7 units.
8. Scan a second lot and scan the packaging again -> Second issue: the packaging quantity is added to the first line, not the second one.

Explanation
===========
About the first issue, it is the expected behavior. When the user scans a lot, we increase the line quantity by 1. When the user scans a packaging, we increase the line quantity by this packaging quantity. The issue here is the user expects to scan a lot and then to apply a packaging quantity to it. For example, scanning a lot then a pack of six should result by a line with 6 units, not 7.

Fix
===
With this commit, the scanned quantity (thus the scanned packaging) for product tracked by lots aren't apply directly on some line but keep in a buffer, with a message to let the user what they scanned until here. Then, when the user scans a lot, only then the quantity is assigned to the scanned lot.
So, the logic and expected flow is:
1. The user scans a product or a packaging;
2. Then they scan a lot;
3. The previously scanned quantity is assigned to the scanned lot.

[task-6216921](https://www.odoo.com/odoo/966/tasks/6216921)

1. Open Helpdesk > Configuration > SLA Policies and create a policy on the team "Customer Care" with "In Progress" as target stage
2. Create two tickets on that team and move them to "In Progress" well before their deadline, so their SLA is reached on time, and leave a third one in "New" with its SLA still running
3. Open Helpdesk > Reporting > Ticket Analysis, enable the "SLA Success" filter and group by "Helpdesk Team", then by "Stage"
4. Click the cell of the "In Progress" stage -> the list of tickets it opens does not hold the number of tickets the cell was showing

Ticket Analysis only offers aggregated views, so its cells count rows of helpdesk.ticket.report.analysis while clicking one re-queries helpdesk.ticket, and the two evaluate sla_success differently. Both analysis reports compute it as "the deadline lies in the future", which is what helpdesk.ticket.sla_success did until odoo/enterprise#85412 aligned it on "reached before the deadline". The two SQL views were left behind, so they label an ongoing SLA as a success and a reached one as a failure once its deadline has passed.

With this commit, Ticket Analysis mirrors helpdesk.ticket.sla_success and SLA Status Analysis mirrors the 'reached' branch of its own sla_status, so the cells agree with the tickets they drill down to.

Task-6523661

# How to reproduce
- Go to Settings > Default Terms & Conditions > Preview
- Open the editor
- Add a Content Block
- Add an Accordion in that Block
- Save

# The issue
The accordion gets messed up and trying to add a new item to that accordion raises a traceback

# Cause
`invoice_terms_html` is an html field with some sanitization enabled : https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/account/models/company.py#L172

This sanitization will remove the accordion snippet's buttons that controls the functionality of the snippet :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website/views/snippets/s_accordion.xml#L9

This issue was already addressed by :
https://github.com/odoo/odoo/commit/b6b4db5fb5690436a4284f6a22abf9f3b346a324

But it is not enough in the case of the accordion. The buttons will be removed by the lxml clean.Cleaner :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/odoo/tools/mail.py#L364

# Proposed Solution
Disable sanitization entirely, like for blog's content, which can also be edited in the website editor :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website_blog/models/website_blog.py#L29

opw-6500378

Forward-Port-Of: odoo/odoo#285255

#### Description of the issue/feature this PR addresses:
When consolidating PoS orders for MyInvois, about one Consolidated Invoice is expected per PoS config(although  could be more than 1). When several configs sell during the same period, the wizard instead creates hundreds of documents each covering only around 100 orders.

#### Current behavior before PR:
_split_pos_orders_in_lines groups the session orders with itertools.groupby keyed on config_id, but the recordset is sorted using pos.order._order ("date_order desc, name desc, id desc"), which never orders by config. Since groupby only groups consecutive equal keys, orders of concurrently selling configs interleave and each config change starts a new group, appending an extra line. The wizard creates one document per MAX_LINE_COUNT_PER_INVOICE lines, so the spurious lines multiply the documents.

#### Desired behavior after PR is merged:
The session orders are sorted by config before grouping, so each config forms a single group and yields one line per continuous receipt range, giving one Consolidated Invoice per config. Sorting is stable, so date ordering within a config and the existing receipt continuity check are unchanged.

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

#### Description of the issue/feature this PR addresses:
Rating a Starshipit shipment for an incomplete delivery address makes the whole rating loop fail instead of skipping that carrier. This breaks express checkout (Apple Pay / Google Pay), where the wallet only discloses a partial address before authorization: the customer gets "update postal address" and cannot pay, while manual checkout works.

#### Current behavior before PR:
delivery_starshipit is the only connector that rates a shipment without validating the addresses first, and it ignores the express_checkout_partial_delivery_address context key set by website_sale. The empty street is sent to /api/rates, which answers 200 with {"success": false, "errors": [{"details": "street parameter value is required"}]}, and _send_request turns that into a UserError. As starshipit_rate_shipment lets it propagate, it aborts the rating of every carrier instead of only this one, so no delivery method reaches the wallet. The same happens for errors only the api can report, such as invalid credentials.

#### Desired behavior after PR is merged:
Both the recipient and the warehouse address are validated before the api is called, as the other connectors already do, and the message is returned as an unsuccessful rate rather than raised. Starshipit requires the street, so a streetless address is still refused, but with a neutral message in the express checkout flow since the customer cannot complete it before paying. The Starshipit carrier is simply not proposed among the wallet's options, the other carriers are rated normally, and express checkout completes.

opw-6393393

Forward-Port-Of: odoo/enterprise#129640
Forward-Port-Of: odoo/enterprise#125117

When a tax affects the base of the subsequent ones — `include_base_amount`,
which is how the ISC is set up in Peru — Odoo links the tax line it generates
to those subsequent taxes, so the ISC tax line ends up carrying the IGV in its
`tax_ids`.

The PLE ledgers build their base columns by summing every move line related to
a given tax group, so that ISC tax line was added to `base_igv` as well and the
ISC ended up reported twice: once inside the taxable base and once in its own
column. A line of 1000.00 with 100.00 of ISC and 198.00 of IGV was declared
with a base of 1100.00 instead of 1000.00.

`l10n_pe_edi` already subtracts the ISC from the `cbc:TaxableAmount` of the CPE
sent to SUNAT, so the electronic invoice and the ledger disagreed on the very
same document.

### What changed

The base taxes are now joined only for base lines, instead of repeating the
condition on each of the twelve `base_*` columns. Besides keeping tax lines out
of the base columns, this also stops a tax line from being counted once per
subsequent tax: an ISC followed by both the IGV and the ICBPER produced two rows
in the join, and its own column was reported twice.

### Scope

`_get_ple_report_data` is shared, so this covers the sales ledger 14.1 and the
purchase ledgers 8.1 and 8.2. A configuration where no tax affects the base of
a later one is unaffected: the standard Peruvian chart template has no purchase
ISC, so ordinary IGV-only purchases report exactly the same values as before.

### Tests

- `test_sale_report_isc_base`: an ISC preceding the IGV, on an invoice and on a
  credit note; the base column excludes the ISC.
- `test_sale_report_isc_reported_once`: an ISC followed by the IGV and the
  ICBPER is reported once.

Both fail without the fix.

Supersedes odoo/enterprise#128300, which targeted 19.0.

Forward-Port-Of: odoo/enterprise#131475