**Issue**:
Importing a vendor bill from XML may lead to two taxes being applied to the same product if:
- The product exists in the database.
- It matches a product reference in the XML.
- The product has a default service tax (e.g. 22% S).

**Steps to reproduce**:
- Create a product with a service tax (22% S).
- Ensure you have a test XML referencing that product (see tests for an example).
- Go to Accounting > Vendors > Bills.
- Upload the XML file.
- Observe that the product line has two taxes: 22% G (from XML) and 22% S (from product).

**Cause**:
Two taxes are applied because:
- The tax defined in the product: [Line 875 in `account_move_line.py`](https://github.com/odoo/odoo/blob/767341d4ec6aaa4fbd379827da4baf04e561eb32/addons/account/models/account_move_line.py#L875) which is triggered by [L1285C1-L1288C30 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1285C1-L1288C30)
- Then, the XML tax is also added: [L1012C1-L1016C44 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1012C1-L1016C44)

An attempt to reset the `tax_ids` after setting the product is already present:
  [Line 1319](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1319),
but it is ineffective because the original `tax_ids` are re-applied afterward, dues to side effects.

**Solution**:
There are two possible ways to fix this:
- Make sure `move_line.tax_ids = []` works as intended
- Clean the `move_line.tax_ids` recordset.

Chose the second option as it's simpler and avoids modifying unrelated code

**Additional Notes**:
The tax extracted from the XML does not take into account whether the product is a good or a service. For example, if the tax rate is 22%, the logic return taxes[0] if taxes else taxes will always return 22% G, even if the product should be taxed as 22% S.

To solve this, an extra domain filter is added based on the product type to ensure only applicable taxes are considered.

opw-4844469

Forward-Port-Of: odoo/odoo#220261
Forward-Port-Of: odoo/odoo#218309

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/b14de14f5 [REL] 18.4.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4d3e2cedf [FIX] cf: do not override changes on cancel [Task: 4609695](https://www.odoo.com/odoo/2328/tasks/4609695)
https://github.com/odoo/o-spreadsheet/commit/497461899 [FIX] pivot: support SUM and AVG aggregators for datetime fields [Task: 4945217](https://www.odoo.com/odoo/2328/tasks/4945217)

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: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@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>

**Steps to reproduce**:
1. Enable automatic invoicing
   `Settings -> Sales -> Invoicing -> Automatic Invoice`
2. Configure a payment provider like `Stripe` (not demo)
3. Open the website in an incognito browser and log in as a portal user
4. Add a product to cart and checkout with the portal user's delivery address
5. Complete payment using test card credentials
6. Navigate to the created invoice in Sales

**Observed behavior:**
The invoice email is sent to both the portal user (customer) and the system admin, appearing as if the email is sent "from admin to admin" instead of from the assigned salesperson.

**Root cause:**
When automatic invoicing is enabled and a portal user completes a website purchase, the `_send_invoice()` method uses `self.env['account.move.send']` which runs in the portal user context. The portal user is selected as author, and the email template uses `partner_to` so it is also selected as partner. While sending mail, this triggers the `mail_notify_author` context. Additionally, due to the portal user not having proper email sending permissions, the system adds admin as fallback. As a result, emails are sent by admin, and because of `mail_notify_author`, mail is also sent to admin.

**Solution:**
Changed `self.env['account.move.send']` to `tx.env['account.move.send']` in the `_send_invoice()` method. Since `tx` is created with `SUPERUSER_ID` context, this ensures the invoice sending runs with proper system permissions and uses the transaction's context instead of the portal user's context.
This ensures emails are authored by the correct salesperson, not the portal user.

opw-4760568

Forward-Port-Of: odoo/odoo#221064
Forward-Port-Of: odoo/odoo#220504

[FIX] html_builder, *: backport the ContentEditable plugin
*: test_website, website

This commit backports [this one] in 18.4.

Related to task-4367641

[this one]: https://github.com/odoo/odoo/commit/e4b720d3a8748151b0bd146b1dbed41adf1483af



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


[MOV] html_builder, *: move the ContentEditablePlugin in html_editor
*: html_editor

The goal of this commit is to move the `ContentEditablePlugin` plugin in
`html_editor` as it is responsible of the `contenteditable` attribute.

Related to task-4367641

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

[FIX] html_builder, *: correctly set contenteditable attribute
*: html_editor, website

The goal of this commit is to correctly handle the `contenteditable`
attribute. This attribute was not handled correctly since the
[website refactoring].

The `contenteditable` attributes have also been removed from the xml in
`website` tests as this attribute is handled by the editor.

Related to task-4367641

[website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

## [FIX] core: python3-magic vs .doc/.xls/.ppt

[python3-magic](https://packages.ubuntu.com/noble/python3-magic)/[python-magic](pypi.org/project/python-magic) (apt/pip) is a frontend for [libmagic](https://manned.org/man/ubuntu-noble/magic) the library that can introspect files to determine their types.

The Documents app makes heavy usage of our mimetypes utilities to scan and fix the extensions of files uploaded by portal users. Everytime a portal user uploads a `.doc`/`.xls`/`.ppt` file, python3-magic is gonna guess the mimetypes `application/x-ole-storage` or `application/CDFV2` which are the mimetypes of the generic file format that Microsoft Office was using until 2006.

The problem is that there is no specific extension for those two mimetypes as Microsoft was using the same file format for many of its office applications.

In this work we enrich python3-magic's detection with our own, which is able to tell different `application/x-ole-storage` and `application/CDFV2` files apart.

**Please note**: Excel files are detected only when the entire file is present. Excel files uploaded via the Documents app are not detected because Documents only `guess_mimetype` on the first 1kiB of the document.

We also added a condition to keep the .doc/.xls/.ppt extension in case the generic `application/x-ole-storage` or `application/CDFV2` mimetype is guessed. Before it was emitting a warning due to the unknown extension.

## [FIX] core: python3-magic vs new (2025) .xlsx files

[python3-magic](https://packages.ubuntu.com/noble/python3-magic)/[python-magic](pypi.org/project/python-magic) (apt/pip) is a frontend for [libmagic](https://manned.org/man/ubuntu-noble/magic) the library that can introspect files to determine their types.

The Documents app makes heavy usage of our mimetypes utilities to scan and fix the extensions of files uploaded by portal users. Sometypes when portal user uploads a `.xlsx` file, python3-magic fails to detect the Microsoft Excel 2007+ (OOXML) mimetype and instead guesses a generic `application/zip`. Technically this is not wrong, OOXML files (like Java JAR and Python Weels) are using the zip format.

This is quite strange because python3-magic is able to work with `.xlsx` files. I'm guessing that Microsoft deployed a new version of Excel and that magic doesn't correctly guess the new (2025) `.xlsx` files. Using a hex editor, the old (from our unittests) and new (from a 2025 support ticket) seem similar: OOXML files, deflate compression, same files present. They are a bit different, in the old the `[Content_Types.xml]` file comes last, in the new it comes first. The zip headers are different too, the old uses zip Data Descriptors, the new doesn't.

The problem is that the Documents app uses the guessed mimetype to "fix" the extension of the uploaded file. So the portal-user's `file.xlsx` gets wrongly rewritten to `file.zip`.

We first used an approach similar to the previous commit[^1], to use our own detection of OOXML files. It works great in base where we run the detection on whole files. However it doesn't work for the Documents app because it attempts to guess the mimetype only reading the first 1kiB of the uploaded file.

A first PR odoo#213647 suggested to change Documents to load the whole file first, and then run `guess_mimetype`, but was rejected.

In this work, we made so we don't fix the extension of zip-like files should the guessed mimetype be application/zip.

[^1]: [FIX] core: python3-magic vs .doc/.xls/.ppt

opw-4607156
opw-4753670

Forward-Port-Of: odoo/odoo#220644

Traceback:
---------
```
Error while render the template
KeyError: 'current_step'
Template: website.step_wizard
Path: /t/div/div[1]/div/div/a/span
```
Ensure `is_published` is set to True for '/shop/extra_info' if the `extra step` feature is enabled during migration.

Cause of the issue:
-----------------------
The issue occurs because the is_published field is set to False, resulting in an empty value for [`current_step`](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale/models/website.py#L799). This happens because the [`allowed_steps_domain`](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale/models/website.py#L780-L783) fails to include the step when the condition is_published=True is not satisfied.

During migration while creation of `website.checkout.step` records, the standard logic `is_published = bool(step.step_href != '/shop/extra_info')` sets `is_published=False` for the [/shop/extra_info](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale/models/website.py#L771) step, even if the extra step feature was enabled in v18.2. This leads to a KeyError when accessing `/shop/extra_info` after migration. This fix ensures `is_published` is correctly
 set based on whether the extra info feature is enabled.

Steps to reproduce:
------------------------
1) In Odoo v18.2, go to Website > Configuration > Settings,
   and enable Extra Step During Checkout
2) Migrate the database to v18.3.
3) Navigate to /shop/extra_info on the website.

Current behavior before PR:
------------
```
v_18.3=# select id,name,key,website_id,active from ir_ui_view where key = 'website_sale.extra_info';
  id  |        name         |           key           | website_id | active 
------+---------------------+-------------------------+------------+--------
 2100 | Checkout Extra Info | website_sale.extra_info |            | f
 2218 | Checkout Extra Info | website_sale.extra_info |          1 | t
(2 rows)

v_18.3=# select id,website_id,is_published,step_href from website_checkout_step where step_href = '/shop/extra_info' and website_id is not null;
 id | website_id | is_published |    step_href     
----+------------+--------------+------------------
  7 |          1 | f            | /shop/extra_info
 11 |          2 | f            | /shop/extra_info
(2 rows)
```

Desired behavior after PR is merged:
------------
```
v_18.3=# select id,website_id,is_published,step_href from website_checkout_step where step_href = '/shop/extra_info' and website_id is not null;
 id | website_id | is_published |    step_href     
----+------------+--------------+------------------
  7 |          1 | t            | /shop/extra_info
 11 |          2 | f            | /shop/extra_info
(2 rows)

v_18.3=# select id,name,key,website_id,active from ir_ui_view where key = 'website_sale.extra_info';
  id  |        name         |           key           | website_id | active 
------+---------------------+-------------------------+------------+--------
 2100 | Checkout Extra Info | website_sale.extra_info |            | f
 2218 | Checkout Extra Info | website_sale.extra_info |          1 | t
(2 rows)
```

upg-2992540
opw-4867915


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

Forward-Port-Of: odoo/odoo#216779

**[FIX] website: remove background color filter when removing bg image**

Since the `html_builder`, when a block has a parallax background image
and the image is removed, any applied color filter remains applied.
This happens because the `editingElement` of the image toggle is the
parallax span instead of the actual section - and therefore the color
filter element is not properly located.

This commit finds out about that situation and removes the filter from
the right element.

Steps to reproduce:
- Drop a "Cover" block
- Remove its background image

=> Its color filter remained present in the DOM.

-------

**[FIX] website: fix parallax in nested block**

Steps to reproduce:

- In Website edit mode.
- Drag and drop a "Tabs" block.
- Drag and drop a "Cover" block inside the "Tabs".
- Add a background image to the "Tabs" block.
- Add a scroll effect (Parallax) to the "Tabs" block.
- Bug: The scroll effect is not applied.

This bug happened because the code checked for a parallax effect in the
whole block structure, not just on the block itself. It wrongly detected
a parallax because a child block had one, even if the parent didn’t.

task-4367641

Before this commit, when you made a self order at Table, the table selector was trigger and you had to pick one, even if the tableIndicator was there.

In practice, the `selectedTable` in `selfOrder` was removed by the `selectPreset()` function of `EatingLocationPage`

```js
selectPreset(preset) {
	this.selfOrder.currentOrder.setPreset(preset);
	this.selfOrder.currentTable = null;
	this.router.navigate("product_list");
}
```

That was fixed in 18.2 by this commit : https://github.com/odoo/odoo/commit/5e01d444cfd0594dd88a420129375ae1a6fdfc62

The test `self_mobile_auto_table_selection_takeaway_in` as been added.

Steps to reproduce (in runbot 18.1) :
- Go in Point of Sale > Configuration > Settings
- Select the Restaurant
- Set the Self Ordering Method to QR menu + Ordering
- Save
- Get the code using Print QR Codes
- Open the Table: 1 URL in incognito window
- Make sure the Restaurant is Open and the table 1 have no remaining order
- Select Eat In as eating location and make an order
- When you click pay, the table selection displayed

opw-4641352

Forward-Port-Of: odoo/odoo#220879
Forward-Port-Of: odoo/odoo#214300

Description
-----------
Writing a new code for an account in the mappings of a COA will retrigger expensive recomputations for all moves linked to the accounts via its lines. This can lead to quick exhaustion of the memory budget for the processing of the request (2 GiB by default).

The commit odoo/odoo@8c5bfff4667ac2f8ec349278dda77d980242aae1 was supposed to address this issue by disabling the fields prefetcher when either 'code' or 'account_type' are being written to, but there is a logical oversight in the condition.
```py
prefetch_fields=any(field in vals for field in ['code', 'account_type'])
```
Means "activate prefetch if it exists a field 'code' or 'account_type' in the vals". This is the opposite of what was intended, if the fields *do not* exist, only then we prefetch. So we can just negate the condition.

Benchmark
---------
For a database where updating the code of an account in the COA mapping, which impacts ~370K account.move and their related ~1.56M account.move.line, saving the new code memory took:

|                   | Before   | After   |
|-------------------|----------|---------|
| Peak Memory Usage | 2.78 GiB | 879 MiB |

Reference
---------
opw-4951670

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

Forward-Port-Of: odoo/odoo#220849

This commit fixes several issues happening when using the "Add Element" grid mode option:

- When the new grid item was added, its options were not activated.
   => This commit fixes that by explicitely activating them (like it was done before the refactoring.

- When adding an image, the image was strangely shifted to the left, inside the column. This is because the image wrongly had the `row` and `o_grid_mode` classes, because the row was passed as the node to replace in the media dialog (the `node` parameter), and the row classes were therefore added on the image, causing their CSS rules to apply on it and shift it.
  => This commit removes the `node` parameter in the call to open the media dialog.

- When adding an image, the dialog which is supposed to only have the "Images" tab also had the "Documents" tab displayed. It happens because the `onlyImages` parameter only disables the "Icons" and "Videos" so, in order to disable the documents, `noDocuments` must also be specified.
  => This commit adds this parameter when opening the media dialog.

This commit also cleans the code, by adding back some missing comments, renaming the variables to follow the convention and give them more correct names, and adding/fixing some docstring.
A major change to note is that the three actions `AddElTextAction`, `AddElImageAction` and `AddElButtonAction`, were merged back into one single `AddGridElementAction`. Indeed, there was no need to define three of them, as only one is needed, with an `actionParam` telling in which case we are (like before the refactoring).

task-4367641

Currently, an error is encountered when trying to load sample data in POS session if the **Administrator** is assigned the **User role** for the Point of Sale app.

**Steps to reproduce:**
- Install the `point_of_sale` module (without demo data).
- Create a new POS session (from list view).
- Change the POS rights of the **Administrator** user from _Administrator_ to _User_.
- Open the pos sessions and on the product screen, click **Load Sample**.

**Error:**
```
while parsing /home/odoo/src/odoo/saas-18.3/addons/point_of_sale/data/scenarios/furniture_category_data.xml:5, somewhere inside
<record id="pos_category_miscellaneous" model="pos.category">
            <field name="name">Misc</field>
            <field name="image_128" type="base64" file="point_of_sale/static/img/misc_category.png"/>
            <field name="sequence">1</field>
        </record>
```

This commit will prevent the error by displaying an **Access Denied** pop-up for users without admin rights, when attempting to load the POS sample data.

Sentry - 6672207110

Forward-Port-Of: odoo/odoo#219103
Forward-Port-Of: odoo/odoo#213813

**Description of the issue/feature this PR addresses:**

When inserting a pivot table in a spreadsheet and grouping by an `id` field,
the pivot column or row headers appear blank instead of showing the expected
label. This issue stems from two inconsistencies:

1. The `_sanitizeLabel` logic used to normalize pivot headers did not properly
   handle groupby values for `id` fields that are returned as `[id, label]`
   arrays. It treated them as truthy values but didn't extract the label.

2. The mock `read_group` implementation did not follow backend logic for `id`
   fields. It returned raw integers instead of `[id, display_name]`, breaking
   the label extraction expected by the pivot UI.

**Current behavior before PR:**
- Pivot headers for grouped `id` fields are blank in spreadsheets
- Mock data returns raw IDs, causing the display logic to fail

**Desired behavior after PR is merged:**
- The pivot UI correctly extracts and displays labels for `id` groupings
- The mock `read_group` aligns with backend by returning `[id, label]` for `id`
  fields, matching the behavior of relational fields

Task: 4878685




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

Forward-Port-Of: odoo/odoo#220880
Forward-Port-Of: odoo/odoo#219206

**Current Behavior:**

The overdraft amount (`lunch_minimum_threshold`) is configured in Lunch
 settings is ignored when employees create or update lunch orders.

As a result, even if the total order amount is within the allowed overdraft limit, 
the system blocks the action.

**Steps to Reproduce:**

1) Install the Lunch module.
2) Set an overdraft amount in the Lunch settings.
3) Ensure an employee's wallet balance is less than a desired order total.
4) Attempt to create a lunch order or increase product quantity such that
   the total is more than the wallet balance but within the wallet + overdraft 
   amount.

**Issue:**

- In both the product view (`_compute_display_add_button`) and
the dashboard (`canAdd` logic), the wallet balance is calculated using
`get_wallet_balance(include_config=False)`.

- This call excludes the overdraft threshold, causing incorrect warnings
and hiding of the `Add to Cart` or `+` buttons.

**Solution:**

- Remove the explicit `include_config=False` argument 
so the default True is used, ensuring the overdraft is included.

- In the dashboard logic, enhance _make_info() to return a 
wallet_with_config key using get_wallet_balance(include_config=True) 
and update the canAdd check to use this value.

opw-4782564

Forward-Port-Of: odoo/odoo#217532

**PROBLEM**
When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the behavior of the import done from the reconcilation page. Also, on the import page, the file name is incorrect (it's always `bank_statement_import.csv`)

**STEP TO REPRODUCE**
file to reproduce the issue : [MP 2280260435_movements_-2025-04-01-191536.xlsx](https://github.com/user-attachments/files/20880784/MP.2280260435_movements_-2025-04-01-191536.xlsx)
1. install the accounting module
2. goes on the dashboard, click on the 3-dot button on the kanban for the bank account, and import a file.
3. make sure the file will be imported in multiple batches (reduced the batch size to 200) and click on import.
4. notice how only the first batch was imported.

**CAUSE**
In python,
The `AccountBankStmtImportCSV` class override the execute_import method of the `base_import.import`. In this override, we add a entry in the `messages` list.
 (see `enterprise/account_bank_statement_import_csv/models/account_bank_statement_import_csv.py`)

In JS,
all entry in messages are treated as errors, and the import is interrupted.
 (see `odoo/addons/base_import/static/src/import_model.js`)
https://github.com/odoo/odoo/blob/389b355e7ec761fe8dc2908ac5aec540b0345c48/addons/base_import/static/src/import_model.js#L410-L417

The message entry added in the python was used in the past to automatically open the reconcillation page with the statement lines added. This feature was removed, but not the message.

**FIX**
- Remove the problematic message entry.
- Fix the name of the file in the import action.

opw-4823808

Forward-Port-Of: odoo/enterprise#91241
Forward-Port-Of: odoo/enterprise#88343