Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c2bb3c8379 [REL] 18.3.46 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/998f03a0d3 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5b5147ef7f [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/66808b6063 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/af50462f8c [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#116811
Forward-Port-Of: odoo/enterprise#115046

__
## Short functional explanation of the error
When creating a Purchase Order. We add a line containing a product
that has an analytic distribution. After setting a project on this PO,
when we add another line containing the same product, the analytic
distribution of the product isn't added anymore, only leaving it with
the analytic distribution of the project.

## Reproduction Steps
1. Go to settings and enable Analytic Accounting.
2. Go to Accounting > Configuration > Analytic Distribution model.
Create a model with a product (prd) you remember, and add an analytic
distribution (ad).
3. Go to Project. On a given project (p), select the Hamburger menu and
click Settings. Then, in the Settings tab, under Analytic, make sure
the Project field is filled.
4. Create a new Purchase Order. Select a vendor and add a line with the
product (prd). On the top right of the Form, click on the view button
and select Analytic Distribution to show it on the form.
There, we should see the product (prd) with its corresponding Analytic
Distribution (ad) on the form.
5. Click on the Other Information tab and select the project (p).
Click on the Product tab. There, under Analytic Distribution field,
you should see (ad) and the Analytic Distribution of the project (p).
6. Click on save and add another line with the exact same product.


### Expected behavior
Under Analytic Distribution, we should see (ad) and the Analytic
Distribution of the project (p), as for the first order line

### Unexpected behavior
Under Analytic Distribution, we only see the Analytic  Distribution of
 the project (p).


## Origin of the issue
When we add another line, we trigger the compute method of the
Analytic Distribution. However, due to this piece of code:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/project_purchase/models/purchase_order_line.py#L14
when we create a new order line, we never compute its analytic
distribution: `self` will contain only `project_lines`, and
`empty_project_lines` is empty as well. Therefore, we call the super
 method with nothing, so when we get in the
super method:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/purchase/models/purchase_order_line.py#L249-L259
we never compute the analytic distribution of the newly created line.

This piece of code was added in this commit:
https://github.com/odoo/odoo/commit/c1ea8446259bd3338c004e88d48ad77ded7ef2ae
to fix the issue that when a user enters manually an analytic
distribution, this entry will be lost when triggering the compute of
the analytic distribution.

However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic 
distribution, as it is much harder to add it again after its removal. 
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.
__
opw-6063418

Forward-Port-Of: odoo/odoo#257558

**Description of the problem**
Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left.

**How to reproduce**
In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown.

**Why the problem happens**
1. Traceback when backspace is pressed
`LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash.
2. No deletion of the character to the left of the cursor
`DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp.

**Fix**
1. Prevent the crash in `LinkPlugin`
`LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns.
2. Fix backspace behavior in `DeletePlugin`
`deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left.

task-6102282

Forward-Port-Of: odoo/odoo#258858

# How to reproduce
- Enable the analytic accounting in the settings
- Create a PO
- Add a PO line
- Set the Analytic Distribution of that PO line to an Analytic Account of your choice
- Confirm the PO
- Create a Vendor Bill from that PO and confirm the VB
- Go to the Analytic Account chosen before
- Change the Plan of that Analytic Account

# The problem
When the Plan is not set to the "Project Plan", the Purchase Orders smart button disappears

# Why
The Purchases Orders smart button is invisible if the variable purchase_order_count is equal to 0. That field is computed by a function that does a search with the following domain :

```py
[('order_line.invoice_lines.analytic_line_ids.account_id', '=', account.id)]
```

When we change the Plan of the Analytic Account, analytic_line_ids.account_id is set to NULL, so the search return nothing.

Why is that field set to NULL ?

Well, to reference its plan, an Analytic Line does not use a python-defined field. In fact, each time a new Analytic Plan is added to the database, a new column is added to the Analytic Line model. That column's name is x_plan{plan.id}_id or, for the specific case of the "Project Plan", it is account_id

When the Plan of an Analytic Account is changed, it takes every Analytic Line associated with that Plan and switch which column containing the id of the Analytic Account.

Take for exemple the following Analytic Line :

```
(account_id = NULL, x_plan2_id = NULL, x_plan3_id = 1)
```

When the associated Analytic Account's Plan is changed to the "Project Plan", it becomes :

```
(account_id = 1, x_plan2_id = NULL, x_plan3_id = NULL)
```

So, we need to adapt to search so that it uses the right plan's name.

opw-5897037

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

Forward-Port-Of: odoo/odoo#263330
Forward-Port-Of: odoo/odoo#248236

Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result:

1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings.
2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself.

Solution
-----
For the first problem, there are a couple things to keep in mind:
- the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer
- products can be added and removed from the picking after the SO has been confirmed
- actual delivery cost can change between invoice date and actual delivery date
- picking can be split into multiple packages at the user's discretion

Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders.

-----
Ticket:
opw-6013387

Forward-Port-Of: odoo/enterprise#111304

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#116897
Forward-Port-Of: odoo/enterprise#110792

Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.

### Steps to reproduce

1. Create an event with a paid ticket (e.g., 100 EUR).
2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR).
3. Open the event registration page.
4. The 100 EUR appears struck-through next to 80 EUR.

### Cause

Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts.

### Fix Rationale

A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount.

opw-5993477

Steps
---------
1. Install Accounting, Sale and Timesheet
2. Create 2 product
    a. Product A - storable - invoiced on Ordered Quantity
    b. Product B - service - create a task on order - invoice on 
    timesheeted
3. Create an SO with 3 product A and 3 product B
4. Add a timesheet line for 1 hour of product A - can be done thanks to 
the button appearing on the SO at confirmation
5. Create Invoice
6. Don't add dates to the wizard and confirm -> Both product appear
7. Add date range that do NOT include the timesheeted lines -> Only the
storable product appear
8. Repeat step 6 -> Only the storable product appear

Problem
---------
During the creation of the invoice, the invoiceable lines would get 
computed dates where provided to the wizard
(`sale.order.line.qty_to_invoice`). When no dates were provided, we
would not manually trigger the invoiceable lines recomputation and were
relying one the data store in cache.

Solution
---------
Force the invoiceable quantity recomputation upon each invoice creation.

opw-6001094

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

Forward-Port-Of: odoo/odoo#261062