Step to reproduce:
- install `l10n_es_edi_verifactu_pos` and open POS
- finalize 2 order with same customer (do not invoive it)
- close session
- go to pos orders, select both order and try to create consolidated invoice

Traceback:
```
File "/home/odoo/addons/l10n_es_edi_verifactu_pos/models/pos_order.py", line 293, in _prepare_invoice_vals
    res['l10n_es_edi_verifactu_refund_reason'] = self.l10n_es_edi_verifactu_refund_reason
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/orm/fields.py", line 1365, in __get__
    record.ensure_one()
```

Cause:
- `_prepare_invoice_vals` is written to accept only one order at time but it can contain multiple orders

Fix:
- we now do not allow invoice consolidation for Veri*Factu
- the consolidation flag has been made invisible so every order now has
to be invoiced individually.

opw-5379577

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

Forward-Port-Of: odoo/odoo#239391

Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and
https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8

**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).

Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration

**Cause**
After the fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 , it will lead
to a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51

**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
was to correct an issue related to the computation of some `project.task`
fields calling a resource method (`get_work_duration_data`), we can revert
the fix and later fix the original issue directly in `project`, without
impacting `hr`/`resource` modules.

opw-5496999
opw-5401425

Forward-Port-Of: odoo/odoo#246779
Forward-Port-Of: odoo/odoo#244052

**Steps to reproduce:**
- Install Email Marketing app
- Create a new campaign with Subject and Recipients
- Set plain text mail body
- Add one image using /img or /image command
- Save the template
- Remove the image
- Save the template
- Try to re-add an image, on save it will be deleted everytime

**Issue:**
During `commitChanges`, the history of the editor is in a wrong state which triggers a cleanup on
`this.wysiwyg.odooEditor.historyRevertCurrentStep();`.

This is caused by the `await saveCallback(element);` of `_onMediaDialogSave` which never resolve and never call its follow-up:
```js
this.odooEditor.historyUnpauseSteps();
this.odooEditor.historyStep();
```
The resolve is event-dependent and doesn't seem to be triggered in current versions:
`const event = $.Event("image_changed", {_complete: resolve});`

**Fix:**
Check that the current element is listening to the given event.
Might not be the proper fix as I wasn't able to reproduce the expected behavior with `image_changed` event.

related PR: https://github.com/odoo/odoo/pull/205594

opw-5245367

Forward-Port-Of: odoo/odoo#244396

*: html_editor

This commit backports [3817cdd], which was properly adapted in 19.0. In 18.4 ([c943a88]), it was kept by mistake as in previous versions, prior to the html_builder refactoring. As a result, the fix didn't work in this specific version.

Original explanation:
On recent versions of Chrome for Linux (v140+), the old SwiftShader software fallback for WebGL has been removed. As a result, new window.WebGLImageFilter() now throws if no GPU context is available, typically when WebGL is disabled or unsupported.

Since the application cannot enable WebGL from JavaScript, this commit improves the user experience by detecting the absence of a WebGL context early and disabling image filters in edit mode. Instead of raising a traceback, the editor now skips the filter feature and can optionally display a friendly message explaining that WebGL is required to use image filters.

This avoids runtime errors and ensures a more robust behavior on platforms where WebGL is unavailable.

[3817cdd]: https://github.com/odoo/odoo/commit/3817cdd3bc096e62dbd017a85356a8032d5217bd
[c943a88]: https://github.com/odoo/odoo/commit/c943a882624900743f02719560b70a0a683f095a

task-5117584

Configuration:
-------------------------
- Restaurant Mode
- Self-Order Mode: “QR + Ordering”
- Service At: Table (Online Payment)

--------------------------------------------------------------------------------
Issue 1: Extra Order word print in KOT
---------------------

Steps to Reproduce:
1. Make an order using Self Order (QR).
2. Configure and enable the Kitchen Printer.
3. Check the KOT print it shows “Order Self-Order T2”.

Cause:
- The QWeb template always prefixed “Order” regardless of order type.

Fix:
- Added a condition to skip the “Order” label for self-order references:

--------------------------------------------------------------------------------

Issue 2: “Send To Kitchen” Button Visible even order in kitchen
---------------
Steps to Reproduce:
1. Open the Restaurant
2. Place a order from mobile menu and select a table.
3. In the Restaurant UI:
   - Open that table. The "Send To Kitchen" button is still visible even
     though the order was already sent to the kitchen and printed.

Cause:
- In self-order mode  the order is not automatically synced after being sent to
  the kitchen and print.
- As a result, the system still treats it as unsent, leaving the Order button
  visible.

Fix:
- Synced the order state after sending it to the kitchen.
----------------------------------------------------

Task-5106704

Forward-Port-Of: odoo/odoo#231005

Problem:
When pasting text or a image URL inside an empty link, or when the link is fully selected, the link is not removed and replaced by the pasted content. Instead, the text or URL is inserted inside the link, which is not the intended behavior.

Cause:
When pasting text or a image URL, and a command is triggered from the powerbox via `openPowerboxOnUrlPaste`, we call `addStep` after the content insertion. This step not only inserts the content but also removes the link if it was fully selected (via `before_paste_handlers`).

However, `onApplyCommand` then restores the state to before the content insertion and link removal. The command (e.g. “Embed Image”) is executed on that restored state, where the selection is collapsed inside the link. As a result, the inserted content ends up inside the link instead of replacing it.

Solution:
In this situation, fully select the link before inserting the content. This allows the `insert` logic to correctly replace the link with the pasted text or URL.

task-5386862

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

The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the tax-included amount, but `total_excluded` (used for the discounted amount) is tax-excluded.

This caused the tax amount to be incorrectly reported as an AllowanceCharge (discount) in the MyInvois XML, because:
  discount_amount = price_unit * qty - total_excluded
                  = tax_included - tax_excluded
                  = TAX AMOUNT (not a discount!)

Example: Product priced at 110 MYR with 10% tax included:
- price_unit = 110 (tax-included)
- total_excluded = 100 (tax-excluded: 110 / 1.10)
- discount_amount = 110 - 100 = 10 ← incorrectly reported as discount

refs:

The cac:AllowanceCharge element in UBL is specifically for discounts and surcharges, NOT for taxes. According to the Peppol Malaysia e-Invoice specification:

https://docs.peppol.eu/poac/my/pint-my-sb/bis/#_allowances_and_charges

https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL5189/ (For this case we are interested in code 95)

Steps to Reproduce:
1. Configure a tax as "Included in Price" with Malaysia tax type
2. Create a product with that tax.
3. Create POS orders without any discount
4. Generate consolidated invoice and XML
5. XML incorrectly shows <cac:AllowanceCharge> with tax amount as discount

The fix uses `raw_total_excluded / discount_factor` (always tax-excluded) instead of `price_unit * quantity` (may be tax-included), consistent with the parent method:
https://github.com/odoo/odoo/blob/d645361a95037ac580d55e80bcb61d1eeb293efd/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1846-L1876

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

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

Forward-Port-Of: odoo/odoo#246490
Forward-Port-Of: odoo/odoo#245535

Scenario:

- add a RTL language to website (eg. arabic)
- go to the website and add a highlight to part of a line
- switch to RTL language

Result: the highlight is not at the correct X position.

This commit fixes the issue for most browser by changing in RTL that:

- the SVG is positionned from the right so the SVG right matches
  the boundary rect right

- mirroring the SVG so when the 1x1 pixel is scaled, it is scaled toward
  the left and it matches the left boundary rect

This is not always working (mostly for safari) because the positionning
of position:absolute SVG inside highlighted position:relative SPAN is
behavior differently in RTL (an even behave differently in case of mixed
RTL / LTR strings in dir:rtl blocks).

This is reproduced in this code:
https://gist.github.com/nle-odoo/21fea59d338b55b3e2a337cf360ef878

So to fix that issue, after inserting a SVG element in RTL in DOM, we
correct the X position by the current error from what we intended.

opw-5049432
opw-5344412
opw-5867908

## PR NOTE:

### 1) For the part:

```diff
-    const firstRect = highlightEl.getClientRects()[0];
+    const rtl = window.getComputedStyle(highlightEl).direction === "rtl";
+    let firstRect;
+    if (rtl) { // Take the first top right element instead of top left
+        firstRect = [...highlightEl.getClientRects()].sort((a, b) => a.top - b.top || (b.left + b.width) - (a.left + a.width))[0];
+    } else {
+        firstRect = highlightEl.getClientRects()[0];
+    }
+
  ...
-        const spanOffsetX = firstRect.x - containerRect.x;
         const spanOffsetY = firstRect.y - containerRect.y;
-        svg.style.left = `${(rects.x - containerRect.x - spanOffsetX) * scale}px`;
         svg.style.top = `${(rects.y - containerRect.y - spanOffsetY) * scale}px`;
         svg.style.bottom = `0px`;
-        svg.style.right = `0px`;
+        if (rtl) { // Position from the right instead of left and mirror the SVG
+            const spanOffsetX = containerRect.x + containerRect.width - firstRect.x - firstRect.width;
+            svg.style.left = `0px`;
+            svg.style.right = `${(containerRect.x + containerRect.width - rects.x - rects.width - spanOffsetX) * scale}px`;
+            svg.style.transform = 'scale(-1, 1)';
+        } else {
+            const spanOffsetX = firstRect.x - containerRect.x;
+            svg.style.left = `${(rects.x - containerRect.x - spanOffsetX) * scale}px`;
+            svg.style.right = `0px`;
+        }
```

I don't understand why the other SVG are positioned relative to the first one(but the original code did that and making it but with the logic of RTL instead of LTR seems to be the only way to make it work).

Note that in saas-18.3 the logic seemed to be a lot more simple, but there was a "display: inline-block;" on the highlight item which simplified the logic a lot (you can just have 100% width to match the item highlighted), but would make (LTR in RTL content, or RTL in LTR content) "`<highlight>hello</highlight> world`" appear in RTL as "`world <highlight>hello</highlight>`".

### Issue:
When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date.

### Steps to reproduce:
- Install 'sale_subscription'
- Create a new Subscription with two lines and a tart data several months in the past
- One with a quantity of 1 and a higher price
- The other with a quantity of -1
- It can be the same service product with invoicing based on ordered quantity
- Confirm the Subscription
- Click "Create Invoice" and confirm the invoice
- Back to the Subscription, the next invoice date was not updated.

### Cause:
In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131

So the method will return not return the date in `invoice_dates`.

Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67

### Solution:
The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds.

To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund.

opw-5360930

Forward-Port-Of: odoo/enterprise#106226
Forward-Port-Of: odoo/enterprise#103705

Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input.

**Steps to Reproduce:**
1. Install the hr_payroll_sale_commission module.
2. Create a user and link to an employee. Set a contract for the employee.
3. Create two commission plans for the same user:
   - Use the same Payslip Input in both plans.
   - Set the Target Frequency to "Monthly" for both.
4. Generate a payslip for the employee.

Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing)

**Error:**
`ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)`

**Cause:**
When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion.

**Fix:**
This commit ensures the currency conversion is applied per commission and prevents the singleton error.

sentry-7187854690

Forward-Port-Of: odoo/enterprise#104600
Forward-Port-Of: odoo/enterprise#104464