**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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/2a7178a06 [REL] 18.3.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/34fdd1eb3 [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/4a1547b56 [FIX] pivot: support SUM and AVG aggregators for datetime fields [Task: 4945217](https://www.odoo.com/odoo/2328/tasks/4945217)
https://github.com/odoo/o-spreadsheet/commit/f23bfa0ca [FIX] data validation: handle cell format in auto-complete [Task: 4865661](https://www.odoo.com/odoo/2328/tasks/4865661)

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:

- In the settings enable "packages" and Multi-Step Routes
- Create a 3 storable products: P1, P2, P3
- Put on hand quantities for each of them:
    - 1 x P1 in PACK001 in stock
    - 1 x P2 in PACK001 in stock
    - 1 x P3 in PACK002 in stock
- Create and confirm a delivery with 3 moves:
    - 1 x P1
    - 1 x P2
    - 1 x P3
- Go to Inventory > Configuration > Warehouse Management > Operation type
- Modify internal transfers to "Move entire packages"
- Create and confirm and internal transfer for PACK001 from stock to the sublocation stock/shelf1
- Mark the package as done and validate the transfer
#### > You end up with 2 quants for PACK002 in stock

### Cause of the issue:

When validating the internal transfer for PACK001, we launch an `_action_done` on the moves lines of the internal transfer. In particular, during this action done, a `quant_cache` will be set for to fetch and use the quants for P1 and P2:
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_move_line.py#L679-L681 https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_quant.py#L933-L949 This cache is correctly use in order to update our move lines during the `synchronize_quant` that will follow:
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_move_line.py#L684-L692 However, they are not in the `_free_reservation` because this call will reassign the move line and then `_check_entire_pack` for the entire picking:
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/addons/stock/models/stock_move.py#L1980-L1981 In particular, it will update the reservation for the move related to P3. But, since the `quant_cache` is taken from the context and did not change it can not find the quants related to P3 and a new quant will be created in addition to the already existing one: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/stock/models/stock_quant.py#L1055 https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/stock/models/stock_quant.py#L1101

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

Forward-Port-Of: odoo/odoo#219049

**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] 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

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

**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

All-day calendar events were incorrectly causing unavailability for
appointment slots scheduled on the previous evening, due to mismatches
between local time and UTC.

Previously, all-day events scheduled for Tuesday were stored with a start time of 00:00 UTC.
In timezones like America/Chicago, this corresponds to 7:00 PM Monday. As a result, a valid
appointment booked from 6:30 PM to 8:00 PM local time on Monday would partially fall into
Tuesday in UTC (ending at 01:00 UTC), causing a false conflict with Tuesday’s all-day event.

The `calendar_verify_availability` method now calls the newly added `_get_date_boundaries`
which than computes naive datetime boundaries based on the user's local timezone by taking
the end of the previous local day and the start of the next local day. 

This change resolves those edge cases where evening slots crossing
the UTC boundary were falsely marked as unavailable due to timezone
misalignment.

opw-4614544

Forward-Port-Of: odoo/enterprise#85654

### Steps to reproduce:

- Create a storable product tracked by lot
- Create and confirm a receipt for 10 units of that product
- Go to the barcode app and regiter 1 unit
- Exit the picking
- Go back to the picking register the 9 remaining units
- Exit the picking and comeback
#### > The demand of the receipt has been updated from 10 to 19.

### Cause of the issue:

Exiting the picking will launch a call of the `post_barcode_process` in order to keep track of the changes you made without changing the initial demand:
https://github.com/odoo/enterprise/blob/c26c21cec14a234021bb13bbc2684334bc64b70b/stock_barcode/models/stock_move.py#L50-L53 THe first time you enter the picking you have a single move with a quantity of 10. The first time you exit, since you have set a qty_done of 1 (and hence have updated the quantity of the associated move to 1), the `split_uncompleted_moves` will then create a move for a quantity of 9 in order to keep 10 units assigned. The second time you enter the picking both moves are grouped in a single line since the product is tracked by lot, however, when you update the qty_done of that grouped line you will actually only update the quantity of the first move line and its related move. Since the `_truncate_overreserved_moves` was not designed to handle these grouped lines, it does not notice that the combined reservation overcomes the actual demand.

opw-4731803

Forward-Port-Of: odoo/enterprise#90497
Forward-Port-Of: odoo/enterprise#89967

Before this commit, when the project is private and the user can only access to some tasks inside that project, he can create timesheets but cannot stop timer in one of those tasks when `industry_fsm` module is installed.

This commit makes sure the user can start/stop a timer on task for which he has access to even if the project is private and he does not have access to it.

Steps to reproduce the issue:
----------------------------

0. install industry_fsm module
1. Create a project A with "followers" as privacy visibility
2. Create a task A and assign it to a project user with lowest timesheet access right.
3. log in as that user
4. Start a timer on Task A
5. Stop the timer and confirm the wizard

Expected Behavior:
-----------------

The timesheet should be created without any issue

Current Behavior:
----------------

An Access error is raised because the user has no access to the project.

task-4680412

Forward-Port-Of: odoo/enterprise#91015
Forward-Port-Of: odoo/enterprise#84807

Steps to reproduce:
-------------------

- Install 'helpdesk_timesheet' module
- Go to Timesheets and click on `Start` to launch the timer
- Select `VIP Support` as Project
- Create a new ticket

Issue:
------

1. Validation error raised: `At least one analytic account must be set.`
2. When we select a helpdesk project that does not have any ticket linked to it already, the field next to it is set to `Task` (task_id) instead of `Ticket` (helpdesk_ticket_id).

Cause:
------

1. When creating the ticket, we don't provide the default project who got the analytic account linked to it.
2. The field `helpdesk_ticket_id` is hidden because we consider that we the project is not linked to any helpdesk team; this is because we retrieve the projects based on tickets already created only.

Solution:
---------

1. Set the default project in the context when creating the ticket (like for a task).
In the create method, if no team is provided and we have a default project (from `list_value` or the `env.context`), we set the team based on the project if the project is linked to a helpdesk team.
2. Fetch all projects that have `helpdesk_team` field set.

opw-4404097

Forward-Port-Of: odoo/enterprise#91110
Forward-Port-Of: odoo/enterprise#76779

**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

### Steps to reproduce:
	- Create an accrual plan with the following rule: 
	— The employee has 20 days off in the first year. Total 20. 
	— The employee has 21 days off in the second year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 21 + 5 = 26 
	— The employee has 22 days off in the third year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 22 + 5 = 27 
	— The employee has 23 days off in the fourth year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 23 + 5 = 28
	- Create an accrual allocation with the created plan
	- Check future allocation data using 'Balance at the'
	- Notice the following behaviour: — until 31/12/2025 it CORRECTLY shows 20 days available.

		— from 01/01/2026 to 30/06/2026 it CORRECTLY shows 26 days (21 days for renewal and 5 days not used in 2025)
		— from 01/07/2026 it INCORRECTLY shows no days available.

		— from 01/01/2027 to 30/06/2027 it CORRECTLY shows 27 days (22 days for renewal and 5 days not used in 2026)
		— from 01/07/2027 it INCORRECTLY shows 5 days.

		— from 01/01/2028 to 30/06/2028 it CORRECTLY shows 28 days (23 days for renewal and 5 days not used in 2027)
		— from 01/07/2028 it INCORRECTLY shows no days available.

		— from 01/01/2029 it CORRECTLY shows 28 days again.
		— In the following years, after 6 months, one year shows 5 days and the next shows nothing.

### Cause:
The first cause here is that when we have validity for the carryover then we will have two calls in each year one at the start of the year and another at the expiration date of the carryover. So, when we add the days to the allocation we don't consider the second call in the condition and we only check if the allocation.actual_lastcall is equal to one of the start dates for each year

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L588

The second cause where each two years one of them shows the number of carryover days from the previous year, this is happening because when we remove the expiring days for the first year we set the number of days to 0

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L516-L517

And it will be 0 until we loop again and add the days to allocation

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L521-L522

and since this is happening after we already set the expiring days which in this year will be 0 we won't remove those expiring days from the year's allocation data

### Fix:
We add a condition to check if the actual_lastcall is either a date in the start of the allocation or one of the expiration dates for the carryover.

Also, before we set the value of the expiring_carryover_days we call _add_days_to_allocation to calculate on the correct number of days for the plan level we are checking.

opw-4606886

Steps to Reproduce:
- Ensure the `sale_timesheet` module is installed.
- Log in as a user with Timesheet Administrator permissions but without access to the Project module.
- Attempt to open the Timesheets list view results in an `AccessError` due to missing read rights on `project.task`.
- Create a task in a private project linked to a timesheet and open its form view results in an `AccessError` due to missing read rights on `project.project`.

Cause:
- When a user has Timesheet Administrator access but lacks project access, they can view all timesheets, including those linked to tasks with private privacy visibility. However, these users do not have read access to the private tasks themselves.
- The `_compute_commercial_partner` method reads `task_id.partner_id.commercial_partner_id` and `project_id.partner_id.commercial_partner_id`. When a user without read access to `project.task` or `project.project` tries to compute this field, an `AccessError` occurs because the code tries to access these related records without bypassing access rights.

Solution:
- Use `sudo()` on `task_id` and `project_id` when accessing their `partner_id` fields inside the compute method to bypass access rights checks, preventing ` AccessError` for users lacking read permissions.

task-4798066

Forward-Port-Of: odoo/odoo#210826

Steps to reproduce:
-------------------
1. Create a free product
2. Add it to self_order
3. Make a self order with only that product -> Free order

Sicne it's a free order, you will not be asked to pay, which is normal.
However, the issue is, no picking is created for that order!!

Why the issue?
--------------
For a non free self order, we create a picking for it by calling
`_process_saved_order` [1] with `draft` argument set to `True`, either
after paying using the online payment method [2], or after paying it
from the payment wizard [3]. However, since for free orders, we're not
asked at any point to pay, and hence, we're not calling
`_process_saved_order` with `draft=True` at any point, and as
consequence, we're also not calling `_create_order_picking`, no picking
will be created for it.

The fix
-------
After, marking the free order as 'paid', we manually call
`_process_saved_order(True)`. We only do it for the free orders, since
the flow is working as expected for non-free order.

[1]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/point_of_sale/models/pos_order.py#L153C19-L153C31
[2]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/pos_online_payment/models/payment_transaction.py#L64
[3]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/point_of_sale/wizard/pos_payment.py#L70

opw-4739523

**Problem:**
When trying to make a refund in Mexico, with a gift card in the order, the order should be refunded on said gift card.
But when doing so, two problems arise:
- In the case of a gift card, *line[2].refunded_orderline_id* is not set, so we are trying to read the property of an undefined variable.
- Another problem is that the order can not have any line that have a positive subtotal in the case of a refund. This was not taking the gift cards into accounts, as it makes sense for them to be positive in such a case.

**Steps to reproduce:**
- Set your company to a Mexican company
- Make a purchase for a gift card
- Make another purchase for a random product
- Start the refund process and enter the gift card code we created before
- Try to finalize the purchase, a traceback appears
- If we were not trying to read an undefined variable, the purchase would still not go through as some lines are positive in a refund

**Why the fix:**
When refunding with a gift card, we should refill the gift card by the order's cost instead. With this in mind, it makes sense for the gift card to have a positive price even though we are in the context of a refund, which usually only permits negative priced lines.

opw-4892935

All-day calendar events were incorrectly causing unavailability for
appointment slots scheduled on the previous evening, due to mismatches
between local time and UTC.

Previously, all-day events scheduled for Tuesday were stored with a start time of 00:00 UTC.
In timezones like America/Chicago, this corresponds to 7:00 PM Monday. As a result, a valid
appointment booked from 6:30 PM to 8:00 PM local time on Monday would partially fall into
Tuesday in UTC (ending at 01:00 UTC), causing a false conflict with Tuesday’s all-day event.

The `calendar_verify_availability` method now calls the newly added `_get_date_boundaries`
which than computes naive datetime boundaries based on the user's local timezone by taking
the end of the previous local day and the start of the next local day. 

This change resolves those edge cases where evening slots crossing
the UTC boundary were falsely marked as unavailable due to timezone
misalignment.

opw-4614544

Forward-Port-Of: odoo/enterprise#85654

After this commit: odoo/enterprise@9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048 [diff](https://github.com/odoo/enterprise/commit/9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048#diff-de4a628e7837c273b67d71f93efab85b6a9ee957ea702f502066ebcc632a76cbL64)

The condition that handles hiding the basic wage on the payslip was not added —possibly it was missed. That’s why the "Hide basic on PDF" feature doesn’t work, regardless of whether it’s enabled, as the necessary condition is missing in the template.

Steps to reproduce (on runbot):
- In a v18 runbot, open any payslip and go to the salary structure. Enable the "Hide basic on PDF" option.
- Return to the payslip and print it.
- You’ll see that the basic wage is still printed on the payslip.


**Before Fix:**

<img width="669" height="238" alt="payslipbefore" src="https://github.com/user-attachments/assets/2fce67a2-19d8-45d8-88fa-4fc6a1767e68" />

**After Fix:**

<img width="683" height="289" alt="payslipafter" src="https://github.com/user-attachments/assets/adcb0104-9c4e-4a35-ba78-b3f278f6bfda" />

opw-4953831

**Steps to Reproduce:**
- Install `sale_subscription`.
- Create a product (recurring product) with:
    - Type: Service
    - Invoicing Policy: Prepaid/Fixed Price
- Create a subscription plan Yearly with:
    - Billing Period: 1 year
    - Align to period start: enabled
- Create and confirm a subscription for the product using the Yearly plan.
- Create and confirm the first invoice (shows remaining days like 
    185 days – 06/30/2025 to 12/31/2025 in product description).
- Create and confirm second invoice (check 1 year – 01/01/2026 to 12/31/2026).
- Go back to the subscription and create an upsell.
- Confirm the upsell and generate its invoice.

**Observation:**
- The upsell invoice line shows the wrong duration: 
    1 year (06/30/2025 to 12/31/2026).
- This is incorrect because the expected duration is: 
  185 days (from 06/30/2025 to 12/31/2025) + 1 year (01/01/2026 to 12/31/2026)

**Issue:**
- The duration calculation is based on the ratio of the first date and the end 
  date, but for the Upsell's ratio is always 1, so it considers fix duration, 
  i.e 1 year, 1 month
https://github.com/odoo/enterprise/blob/4bb43da79dba7ac1d0772fde814b3da6bade7db6/sale_subscription/models/sale_order_line.py#L346-L347

**Solution:**
- Corrected the logic to calculate the upsell duration by combining the remaining
  current period (e.g., 185 days) with the standard 1-year period ratio.

Reference PR: https://github.com/odoo/enterprise/pull/68163/commits/cfed2d369960896f0f4d91a90eb24f3641627419
opw-4853426