Steps to reproduce:
-------------------------------------
1. Open the chatter of any record
2. Open the full composer for the Log Note
3. Add some text and paste some images > Post the log note
4. Click on the Edit option
5. Save the message without editing anything

Observation:
-------------------------------------
You will notice that the (edited) label appears even though the message wasn't edited at all, only the edit mode was made active.

Issue:
-------------------------------------
When a message is posted via the mail composer, the email conversion pipeline injects MSO conditional comments like
`<!--<![endif]-->` and `<!--[if mso]>...<![endif]-->` into the HTML body. These comments are added by the `_hideForOutlook` and `createMso` https://github.com/odoo/odoo/blob/083e091eaa7d983f6c826c02b0d0652a821227fb/addons/mail/static/src/views/web/fields/html_mail_field/convert_inline.js#L1978-L1988

https://github.com/odoo/odoo/blob/083e091eaa7d983f6c826c02b0d0652a821227fb/addons/mail/static/src/views/web/fields/html_mail_field/convert_inline.js#L1699-L1707

functions to ensure Outlook compatibility, they wrap responsive elements so that Outlook receives simplified table-based fallbacks while modern clients see the original layout. The stored message body on the server retains these comments. When a user clicks "Edit" on such a message, the body is loaded into the OdooEditor. The browser's DOM parser treats `<!--<![endif]-->` as standard HTML comment nodes, which are not preserved in `innerHTML` serialization. So the editor returns the body without these comments, even if the user made no changes. The `edit()` method in then compares `updatedBodyEl.innerHTML` (from editor, no comments) against `messageBodyEl.innerHTML` (from server, has comments), finds a difference, and sends a update to the backend, which stamps the message with the (edited) label.

Solution:
-------------------------------------
Before comparing innerHTML, strip all HTML comment nodes from both the original and updated body elements. This is done on throwaway DOM elements created solely for comparison. The actual body sent to the server (`body` parameter) is never modified.

Note:
-------------------------------------
An alternative approach would be to strip comments at the string level using a regex (`html.replace(/<!--[\s\S]*?-->/g, '')`) before creating the DOM elements. This is valid since HTML comment syntax `(<!--...-->)` is strictly defined and no nesting is allowed, so the regex is reliable.

opw-6328529

Issue:
Colombian child contacts linked to a NIT company are displayed with their standalone name instead of "Company, Contact". Searching Contacts by the company name consequently returns the company but not its child contacts.

Steps to reproduce:
- Create a Colombian company with NIT
- Add a child contact or address to that company
- Filter Contacts by the company name
- Observe that the child is displayed separately and is not returned

Cause:
The Colombian `is_company` computation classifies every partner with a Colombian NIT and qualifying obligations as a company: https://github.com/odoo/enterprise/blob/911686a31d5d3c1539d0dff7d16edf1ce9b101ca/l10n_co_edi/models/res_partner.py#L43-L53

Those fiscal values are commercial fields and are propagated to child contacts. Without checking that the partner is its own commercial entity, children are therefore classified as companies, preventing the standard display name logic from prefixing their parent name.

Solution:
We need to restrict the Colombian company classification to partners that are their own commercial partner. This preserves the NIT and obligation rules for actual companies while keeping their inherited child records as contacts, restoring both the combined display name and parent name search behavior.

opw-6470958

Forward-Port-Of: odoo/enterprise#128986

TL;DR
- we lose the measures from arch after a reload, if removed from activeMeasures

Step to reproduce:
- install pos, create few orders
- go to reporting> orders> switch to pivot view
- click the `Measures` dropdown,  `Order` is already selected
- untick it, then apply some filter so that view reloads (ex order date)
- reopen `Measures` dropdown, notice `Order` is missing form measures

Cause:
- view `view_report_pos_order_pivot` has `<field name="order_id" type="measure"/>`  in its pivot view
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/point_of_sale/views/pos_order_report_view.xml#L10
- `order_id` is M2O field
- Measure is compute from present `activeMeasure` and fields of type `["integer", "float", "monetary"]`
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/utils.js#L89-L120

- when the view is first loaded, `activeMeasure` all the fields with `type="measure"` which is directly passed to pivot's model as a metadata
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_arch_parser.js#L59-L60

https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_view.js#L41
- when we toggled the `order_id` from measure and reloaded, `order_id` is popped from  `activeMeasure` and as it's field type is `many2one` it is not considered for `measures` in `computeReportMeasures`

Fix:
- maintain the measures from arch separately and feed it to `computeReportMeasures`

opw-6416196

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

Forward-Port-Of: odoo/odoo#286013
Forward-Port-Of: odoo/odoo#278850

Two module manifests hold a `description` whose reStructuredText does not parse. Both are rendered by `ir.module.module._get_desc` (these modules have no `static/description/index.html`, so the RST path is the one used on the Apps page).

### `mail`

The line introducing the list of email-enabled documents is followed by a row of dashes. In reStructuredText an underline directly below a line of text makes it a section title, so docutils treats a 102-character sentence as a heading, then fails on the indented list that follows without a blank line:

```
<string>:38: (ERROR/3) Unexpected indentation.
<string>:43: (WARNING/2) Block quote ends without a blank line; unexpected unindent.
```

These are logged every time the description is rendered, and the bullet list ends up rendered as a block quote instead of a list. The dashes are dropped, since the line is a regular sentence and not a section title, and the list is surrounded by blank lines.

### `l10n_tw_edi_ecpay`

The whole description is indented, which makes reStructuredText read it as a block quote. A section title is not allowed inside a block quote:

```
<string>:3: (SEVERE/4) Unexpected section title.
```

At SEVERE level this reaches the default `halt_level`, so rendering raises instead of returning a document and `_get_desc` falls back to showing the raw description in a `<pre>` block. The indentation is removed.

---

Checked by rendering the `description` of every manifest under `addons/` and `odoo/addons/` with the same docutils settings `_get_desc` uses: these were the only two that reported anything, and both are clean after the change.

Forward-Port-Of: odoo/odoo#285323
Forward-Port-Of: odoo/odoo#284360

stock_*:
stock_account, stock_dropshipping, stock_landed_costs 

**Problem:**
dropship moves impact the average cost 
of products which can lead to negative balance 
in stock valuation account

**Steps to reproduce:**
On a new db with no demo data and stock_dropshipping, 
sale_management and accountant module installed 
(bug also reproducible in runbot with same steps, 
but it's easier to see the negative impact 
on accounting on a new db) : 
1) enable dropshipping
2) create a storable product with average perpetual
category
3) in the purchase tab set a vendor with a price of 10
4) in the inventory tab select the dropship route
5) create PO for 1 unit @ 5, validate receipt and confirm bill
6) confirm a SO for 1 unit of the product
7) confirm linked PO and validate dropship move
8) confirm invoice and vendor bill 
-> see how the standard price is now 7.5

9) remove dropship route from the inventory tab of 
the product
10) confirm a SO for 1 unit of the product
11) validate delivery and confirm invoice
12) open 'inventory valuation' view

**Current behavior:**
the initial balance of stock valuation is -2.5

**Expected behavior:**
it should be 0 (there shouldn't be a negative 
initial balance if all invoices and bills are confirmed)

**Cause of the issue:**
The issue happens after step 8)
The problem is that the dropship has an impact on the 
average price of the product but not on the accounting.

Before the dropship we have 1 unit in stock @ 5
and the stock valuation account has a balance of 5 
(from the bill), so all is good.

The dropship then changes the standard price to 7.5.
That's because currently, in _run_average_batch()
the dropship move first impacts average cost like 
an incoming move with a value of 10 (at this point we 
have 1 move @ 10 and 1 @ 5 so average cost is 7.5)
https://github.com/odoo/odoo/blob/bcaa8b6b00fa1f16513d680c5187fd424bc7cf8c/addons/stock_account/models/product.py#L493-L500
https://github.com/odoo/odoo/blob/bcaa8b6b00fa1f16513d680c5187fd424bc7cf8c/addons/stock_account/models/product.py#L505-L510

and then it impacts the value as a regular outgoing move
(meaning it leaves the inventory at the average cost of 
7.5) and does not impact the average cost (which is the 
basic behaviour of outgoing moves)
https://github.com/odoo/odoo/blob/bcaa8b6b00fa1f16513d680c5187fd424bc7cf8c/addons/stock_account/models/product.py#L515-L517
https://github.com/odoo/odoo/blob/60b5b99d569dbe183ef9c980217ccfe9bf243756/addons/stock_account/models/product.py#L522

Therefore after step 8), the standard price is 7.5 and 
we have a unit in stock so, in the inventory valuation 
view the ending stock is 7.5$. 
But the dropship did not impact the stock valuation 
account so the initial balance is still 5$ and we have 
lines with credits and debits of 2.5$ in the the stock 
variation section.

After steps 9 to 12, both the initial balance and ending stock
decrease by 7.5 (which is expected), leading to a negative
initial balance in stock valuation.

**fix:**
We don't take into account the stock move 
from dropships in the avco computation

**tests:**
The fix requires modifications in a few tests:
- test_dropship_bill_standard_price_update 
checks that  the bill of a dropship move impacts
the standard price, so we delete this test
- test_lot_normal_3, the asserts on the total_value 
still make sense but not those on standard_price
- test_dropship_kit_bom_updates_component_standard_price
test_average_cost_dropship_in_negative_quantity,
test_out_move_validate_as_stock_user:
standard price should not be impacted by dropship

Task 6515358

Forward-Port-Of: odoo/odoo#285576

### Problem

`label` on `account.reconcile.model.line` is a **translatable** field, but its value is
written onto the journal item created when the model is applied (`account.move.line.name`).

That means the label is read in the language of whoever applies the model:

- a user working in another language writes the translated value;
- the auto-reconciliation cron writes the **source** value, since it runs as OdooBot.

So the very same reconcile model ends up writing two different labels on the journal items,
depending on who applied it.

### How it shows up

It becomes visible when a reconcile model is created by **duplicating** an existing one and
the label is then edited while working in a non-source language. The translation holds the
new text, while the source value silently keeps the label of the original model — and the
source value is exactly the one the cron writes. The result is a set of journal items where
some carry the intended label and some carry the label of an unrelated model.

### Fix

The journal item belongs to the company, so the label is read in the **company** language
via a small `_get_aml_label()` helper, instead of the language of the current environment.
It falls back to the current behaviour when the company has no language set.

`_prepare_aml_vals()` is the only place in 18.0 that reads `self.label` for the journal item.

### Test

Adds `TestBankRecWidget.test_auto_reconcile_model_label_uses_company_lang`: a reconcile model
whose line label is translated in the company language, applied by the auto-reconciliation
cron running in the source language, and asserts the journal item carries the company-language
label.

```
odoo -d <db> -u account_accountant --test-enable --stop-after-init \
  --test-tags /account_accountant:TestBankRecWidget.test_auto_reconcile_model_label_uses_company_lang
```

Without the fix the test fails with `[{'name': 'Frais bancaires'}] != [{'name': 'Bank fees'}]`;
with the fix it passes. The full `account_accountant` suite was also run on a clean 18.0
database: 203 tests, 0 failed, 0 errors.

Forward-Port-Of: odoo/enterprise#130719
Forward-Port-Of: odoo/enterprise#128433

**Steps to reproduce:**
* Install `l10n_co_dian`.
* Configure a company with the Colombian localization.
* Set up a DIAN operation mode for Electronic Invoices only (no Support Documents mode).
* Create a vendor bill marked as a Support Document and click **Send to DIAN**.

**Observed behavior:**
* A cryptic server error is raised: *"TypeError: unsupported operand type(s) for +: 'int' and 'str'"*
* No actionable information is shown to the user.

**Cause:**
* `_add_document_config_vals` assigns `vals['l10n_co_dian_operation_mode']` via `.filtered()`, which returns an empty recordset when no matching operation mode exists.
* Accessing a `Char` field on an empty recordset returns `False` (a `bool`, which is a subclass of `int` in Python).
* Concatenating `False` with strings in the `sha384` hash calculation raises the `TypeError`.
* The missing-mode guard only existed in the commercial events path, not in the main invoice export path.

**Fix:**
* Raise a descriptive `UserError` that tells the user which mode is missing and where to configure it.

opw-6499321

Forward-Port-Of: odoo/enterprise#128935

### Issue:
An unexpected `<SchmeNm><Cd>CUST</Cd></SchmeNm>` node was added inside `<InitgPty><Id><OrgId><Othr>` for all countries
Some Italian banks reject SDD files containing this node

### Cause:
https://github.com/odoo/enterprise/commit/3c3c64b511d07fc1ba33c30363972f5b0f7283d6 added `<SchmeNm><Cd>CUST</Cd></SchmeNm>` unconditionally for all countries
The original fix was intended for Nordea (Sweden) only, which requires this node explicitly
The assumption that other countries would accept it was incorrect

### Steps to reproduce:
- Install `account_sepa_direct_debit` and `l10n_it`
- Switch to the IT company
- In Settings, set SEPA Direct Debit Creditor Identifier to `BE30ZZZ300D000000042`
- Create and confirm a Payment (Method: SEPA Direct Debit, any customer and amount)
- Create and validate a Batch Payment with that payment
- Open the generated PAIN008 XML

Before the fix, `<SchmeNm><Cd>CUST</Cd></SchmeNm>` is present

opw-6530996

Forward-Port-Of: odoo/enterprise#130304