### Steps to Reproduce:
1. Activate l10n_de
2. Navigate to the General Ledger and export the "Datev DATA"
3. Column D, "Kurs," is incorrect

### Description of the issue/feature this PR addresses: 
**Issue:** DATEV documentation states that the column for "Kurs" should be the ratio of WKZ-Umsatz : WKZ-Basisumsatz, which is Foreign : Base Currency. Additionally, all sample files show this column's values being rounded to 6 decimal places. Currently, when Odoo exports the general ledger as DATEV data, there is no rounding of decimal places and the formula does base / foreign amount, `line_amount / line_amount_currency`.

**Solution:** In the `datev_export_csv.py` file, the relevant method is called `_l10n_de_datev_get_csv()`. In there, we can fix the line to round the value of `line_amount_currency / line_amount` to 6 decimal places.

### Current behavior before PR: 
Exporting the general ledger as DATEV data currently gives the reverse foreign currency rate and fails to round to 6 decimal places, which causes some values to be extremely long.

### Desired behavior after PR: 
The csv files should output the correct rate and be rounded appropriately.

**Releted Documentation:** https://developer.datev.de/en/file-format/details/datev-format/format-description/booking-batch

opw-6366276s

Forward-Port-Of: odoo/enterprise#125097

The AutoComplete component wraps a text input that already renders its
own suggestion dropdown, so the browser's native suggestions must stay
out of the way. In 12/2024 in this commit [1] the input's autocomplete
was switched from `off` to `new-password` on the premise that `off` is
not respected by browsers. In 02/2025, in this commit [2] then made it
the component default so many2x pickers stay clean.

Chrome runs two independent suggestion mechanisms, and each attribute
silences only one of them:
- `off` is ignored when the input has a name and Chrome holds autofill
  (address) data for it.
- `new-password` is ignored when Chrome offers "frequently used values",
  i.e. the form-history dropdown. [3]

So `new-password` does not always work. It only stays hidden while the
field is ineligible for those suggestions. A field becomes eligible as
soon as it gains an `id` and an associated `<label>`. On `saas-19.3`
this is provable on commit [4] where adding a prefix icon gave the link
popover URL input an `id` + `<label for>`, and the native dropdown
resurfaced over the custom URL/page suggestions.

This branch targets `saas-18.4`, where the regression is NOT
reproducible because that URL input has no `id`/`label` yet. The fix is
applied here anyway to avoid the gap that any later `label`/`id`
addition re-exposes (as commit [4] proved), and the fix can be forward
ported to `saas-19.3`.

The website editor's URL field implements autocomplete without the
`AutoComplete` component, so the default does not reach it. so
`autocomplete="off"` is set directly on that input.

[1]: https://github.com/odoo/odoo/commit/9c0f5612
[2]: https://github.com/odoo/odoo/commit/2980694b (opw-4551051)
[3]: https://issues.chromium.org/issues/41163264#comment30
[4]: https://github.com/odoo/odoo/commit/2b4d04d1 (task-6034288)

task-6370552

Forward-Port-Of: odoo/odoo#279560
Forward-Port-Of: odoo/odoo#277501

Issue:
When clicking "Send & Print" on an Ecuadorian invoice and sending the email with both the PDF and XML attachments visible in the wizard, only the PDF attachment is sent

Steps to reproduce:
1. Install l10n_ec_edi and enter EC Company
2. Create and post an invoice
3. Click "Send & Print" on the invoice
4. Notice that both the XML and PDF attachments show up on the wizard, but when clicking "Send", only the PDF attachment is attached to the email that gets sent out

Cause:
Before the "Send & Print" wizard opens, the XML is already created. When opening the "Send & Print" wizard, the XML is added to the wizard with a "skip: True" flag. This is used for the wizard dropdown to add already existing attachments on the invoice. When the attachment is not selected, it makes sense to not be sent. However, when the "Send & Print" wizard opens, the attachment is added by default and the attachments in the dropdown does not consider the attachments already attached to the wizard at the start. The duplicated attachment in the dropdown has the "skip: True" flag still so it will wrongly signal later on that the attachment should not need to be sent

Solution:
When loading invoice attachments into the wizard, skip any attachment that is already present in the wizard's attachment list, so that default send attachments are not accidentally duplicated with the skip flag

opw-6351635

Forward-Port-Of: odoo/odoo#278985

When a PoS runs in a currency other than the company currency, product prices are loaded already converted to the PoS currency (`list_price`, `lst_price`, `standard_price` all go through `_convert_pos_data_currency`).

The prices carried by combos were not: `product.combo.base_price` is computed in the combo currency (the company currency) and `product.combo.item.extra_price` is stored in the product currency, but neither was converted when loaded in the PoS. As a result, a product priced at 2 USD (= 80 ZIG) was correctly shown as 80 ZIG on its own, yet appeared as 2 ZIG once it was part of a combo, since the raw amount was displayed as-is in the PoS currency.

Convert `base_price` and `extra_price` from each record's own `currency_id` to the PoS currency at load time, mirroring what is already done for product prices.

Steps to reproduce:
- Set a product to 2 USD and a PoS to a ZIG pricelist (rate 40).
- Open the PoS: the standalone product shows 80 ZIG.
- Add the same product as a combo item: it shows 2 ZIG instead of 80 ZIG.

opw-6410243

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

Forward-Port-Of: odoo/odoo#279253
Forward-Port-Of: odoo/odoo#278330

## [FIX] timesheet_grid: remove duplicate rpc call

Before this commit, the `loadTimesheets` method is called 2 times in a
row, that method does a rpc call to load the existing timesheets and so,
it is not needed to call it 2 times since the rpc will return the exact
same result.

This commit removes the rpc call when we compute the suggestions to only
load the timesheets when we load all the data.

## [FIX] timesheet_grid: show chronological view instead of project view

Before this commit, the `by project` view were loaded first in the
timesheet assistant action, to group the suggestion by project, the
problem is at the beginning the view will not really show a perfect
matching and so the user could think the feature does not work and he
will not understand how to correctly match the suggestions shown in the
view.

This commit changes the view loaded by default in Timesheets Assistant
to first show the chronological view, that view is more logical for the
current user to rethink what he did in the past to correctly map the
events to a project and a task when he generates his timesheets thanks
to those events. The by project view is still useful afterwards when the
system has learned the choices made by the current user.

## [FIX] timesheet_grid: ensure events are consumed forever

Before this commit, the suggestions removed by the current user comes
back when he changes the date and come back to the day he removes the
suggestions. The reason is because a shallow copy of events consumed is
made and that copy alters the duration of the initial object.

This commit avoids copying the consumed events object to make sure the
initial object is not altered when processing the events to remove them
if they are removed before by the user.

### Steps to reproduce the issue:

1. install timesheet_grid and Activity watch, makes sure Activity watch
collects some activities on your computer.
2. Go to Assistant menu in timesheets app.
3. Remove some suggestions displayed in the right panel.
4. Go to next date.
5. Come back to previous date.

### Expected Behavior:


The suggestions removed should not appear again.

### Actual Behavior:

The suggestions removed come back in the view.

## [FIX] timesheet_grid: fix flicker when suggestion selected

Before this commit, when the user selects a suggestion in timesheet
assistant, there is a small flicker appears because the height of the
row grows because of the border added to highlight the suggestion
selected.

This commit reviews a bit the style to make sure the border bottom in
the previous element is removed if the element is not selected or if the
2 consecutives suggestions are selected.

## [FIX] timesheet_grid: fix discord rules to handle discord in web

Before this commit, when the user uses discord in its browser instead of
the app on his computer, the discord rules don't catch the activity
watch events because the tab title is different than the windows name in
the app.

This commit adapts the regex of Discord rules to handle the both use
cases.

task-[6385639](https://www.odoo.com/odoo/project.task/6385639)

Forward-Port-Of: odoo/enterprise#124855

When a PoS runs in a currency other than the company currency, product prices are loaded already converted to the PoS currency (`list_price`, `lst_price`, `standard_price` all go through `_convert_pos_data_currency`).

The prices carried by combos were not: `product.combo.base_price` is computed in the combo currency (the company currency) and `product.combo.item.extra_price` is stored in the product currency, but neither was converted when loaded in the PoS. As a result, a product priced at 2 USD (= 80 ZIG) was correctly shown as 80 ZIG on its own, yet appeared as 2 ZIG once it was part of a combo, since the raw amount was displayed as-is in the PoS currency.

Convert `base_price` and `extra_price` from each record's own `currency_id` to the PoS currency at load time, mirroring what is already done for product prices.

Steps to reproduce:
- Set a product to 2 USD and a PoS to a ZIG pricelist (rate 40).
- Open the PoS: the standalone product shows 80 ZIG.
- Add the same product as a combo item: it shows 2 ZIG instead of 80 ZIG.

opw-6410243

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

Forward-Port-Of: odoo/odoo#279253
Forward-Port-Of: odoo/odoo#278330

### Steps to Reproduce:
1. Activate l10n_de
2. Navigate to the General Ledger and export the "Datev DATA"
3. Column D, "Kurs," is incorrect

### Description of the issue/feature this PR addresses: 
**Issue:** DATEV documentation states that the column for "Kurs" should be the ratio of WKZ-Umsatz : WKZ-Basisumsatz, which is Foreign : Base Currency. Additionally, all sample files show this column's values being rounded to 6 decimal places. Currently, when Odoo exports the general ledger as DATEV data, there is no rounding of decimal places and the formula does base / foreign amount, `line_amount / line_amount_currency`.

**Solution:** In the `datev_export_csv.py` file, the relevant method is called `_l10n_de_datev_get_csv()`. In there, we can fix the line to round the value of `line_amount_currency / line_amount` to 6 decimal places.

### Current behavior before PR: 
Exporting the general ledger as DATEV data currently gives the reverse foreign currency rate and fails to round to 6 decimal places, which causes some values to be extremely long.

### Desired behavior after PR: 
The csv files should output the correct rate and be rounded appropriately.

**Releted Documentation:** https://developer.datev.de/en/file-format/details/datev-format/format-description/booking-batch

opw-6366276s

Forward-Port-Of: odoo/enterprise#125097

**_Steps to reproduce:_**

* Install `l10n_br_avatax` and configure Avalara Brazil.
* Create at least two customer invoices.
* Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**.
* Select the invoices and click **Action → Confirm Entries**.

**_Observed behavior:_**

* A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated.

**_Cause:_**

* During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records.
* Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices.

**_Fix:_**

* Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`.
* This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error.

opw-6334761

Steps to reproduce:
- Configure a preparation display on a POS config with a product category
- Place an order and leave it in a non-final stage
- Keep the session open past midnight

Issue:
The kanban order-count badge drops the order once its create_date falls behind "today", while the preparation screen still lists it. The same divergence makes the badge keep counting an order that a "Reset" already removed from the screen.

_compute_order_count() scoped its search on pos_config_id and create_date >= today, whereas the screen is built by get_preparation_display_order() from _get_open_orders_in_display() and _get_stageless_orders_in_display(), which have no date filter and instead bound the set by the order stage `done` flag and the session state. An order open across midnight is therefore in the screen set but not in the badge set. Conversely reset() marks the current stage done, which drops the order from the screen set, but the badge only skipped orders whose latest stage is the final stage, so an order reset while still in the first stage stayed counted.

opw-6414302

Forward-Port-Of: odoo/enterprise#126139
Forward-Port-Of: odoo/enterprise#125984

Description of the issue/feature this PR addresses:

Fixes #279931.

`initElementForEdition()` ([`html_editor/static/src/utils/sanitize.js`](https://github.com/odoo/odoo/blob/18.0/addons/html_editor/static/src/utils/sanitize.js#L20-L31)) removes the `width`/`height` attributes of every `<img>` in the editable and replaces them with an inline pixel style. Its comment says *"The attributes will be re-applied on save"*, and for the pipeline it was written for that is true: `convert_inline` re-adds `width` from `style.width` when it inlines a body for email.

But `initElementForEdition()` is called unconditionally from [`editor.js`](https://github.com/odoo/odoo/blob/18.0/addons/html_editor/static/src/editor.js#L109), on every editor start, for every editable — website pages, blog posts, any `html` field on `html_editor`. Outside the mail path nothing re-applies the attributes.

This was added by #213786 (`opw-4863515`, forward-ported as #216958 / #216986 / #217002 / #217017 / #217023) to fix a real problem in the *email template* editor, where `convert_inline` had added `width`/`height` for email-client compatibility and those attributes then prevented resizing an image back to its default. That fix is right for that path. This PR only narrows where it applies.

Current behavior before PR:

Open any editable containing an image with intrinsic dimensions, type one character, save. The stored markup is permanently rewritten:

```
before  <img src="…" alt="x" width="960" height="540" loading="lazy">
after   <img src="…" alt="x" loading="lazy" style="width: 960px; height: 540px;">
```

There is no way back — on the next edit `img[width]` no longer matches, so the inline style stays.

It is not cosmetic. Intrinsic `width`/`height` is how a browser reserves the box before an image loads, and an inline `width` beats the stylesheet rule that keeps the image responsive. Measured at a 375px viewport with a 960×540 image in a 319px column, after one keystroke and a save:

* the image renders 960×540 — **641px of overflow**, and the document's `scrollWidth` goes from 375 to 1153, so the page scrolls sideways;
* the derived `aspect-ratio` becomes `auto`, so a `loading="lazy"` image below the fold lays out at **zero height** until it decodes — the CLS the attributes exist to prevent;
* where a stylesheet sets an explicit `aspect-ratio`, an explicit `width` **and** `height` together decide the used size, so the declared ratio goes inert and the crop is lost.

Desired behavior after PR is merged:

The rewrite becomes opt-in through a `removeForcedImageDimensions` config flag — following the existing `allowInlineAtRoot` precedent, which is threaded the same way — and is set in `HtmlMailField.getConfig()`, the field whose `getEditorContent()` runs `toInline()`. That is the one path that puts the attributes back, and `HtmlComposerMessageField` inherits it. Every other editable keeps the author's markup.

Behaviour in the email-template editor, which `opw-4863515` was about, is unchanged.

Adds `html_editor/static/tests/utils/sanitize.test.js` covering both directions: with the flag the attributes still move into an inline style; without it they are left alone; an image with no dimensions is untouched either way.

Targeting **18.0** as the oldest affected branch — #213786 targeted 18.0 and the block is byte-identical on `18.0`, `saas-18.4`, `19.0`, `saas-19.1` and `master`.

---

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