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

A traceback occurs when a user removes the Employee field 
while creating a time off allocation record.

**To reproduce the issue:**

1) Install the `Time Off` module.
2) Create a new time off allocation record.
3) Navigate to the `Related Time Off Type` record.
4) Change the `Take Time Off in` option to Hours.
5) Return to the allocation and remove the Employee field.

**Error:**
```
ZeroDivisionError: float division by zero
```

**Cause:**

- When the Employee field is cleared, the `_compute_number_of_days` method is triggered.
- Since the allocation_unit is set to Hours, this method attempts to calculate `number_of_days` 
using `_get_hours_per_day`.
https://github.com/odoo/odoo/blob/96d4bd7911ba122610fd42c009da0a8e565e50ec/addons/hr_holidays/models/hr_leave_allocation.py#L256-L262
- However, when `employee_id` is missing, `_get_hours_per_day` returns 0, 
resulting in a division by zero.
https://github.com/odoo/odoo/blob/96d4bd7911ba122610fd42c009da0a8e565e50ec/addons/hr_holidays/models/hr_employee.py#L140-L143

**Solution:**

Since the employee_id is a required field in allocation, 
Adding an extra check for employee_id will resolve this issue.

opw-4937893

Forward-Port-Of: odoo/odoo#221115
Forward-Port-Of: odoo/odoo#219403

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

## Version
18.0+

## Issue
The tour `snippet_popup_and_animations` times out when trying to wait for the last column to become "not animated and hidden". This happens because the element never actually becomes `hidden` after the scroll-triggered animation ends — it remains in the DOM and visible.

## Cause
Commit 7e85f88214b6b57db87a6c1964286f0b7813f6ff attempted to fix a selector that was always true by adding `:hidden`, assuming the element would be hidden once the scroll animation completed. But since the element’s visibility is never changed via `display: none` or `visibility: hidden`, the `:hidden` condition never matches, blocking the tour.

## Fix
Remove the `:hidden` pseudo-class from the trigger.
Instead, wait for the `.o_animating` class to be removed (indicating the end of the animation), then:
- Add a short delay to ensure animation processing is complete.
- Check that the element is outside of the viewport (scrolled out).
- Verify that `animation-delay` is approximately 0.


runbot-227077

Forward-Port-Of: odoo/odoo#219979
Forward-Port-Of: odoo/odoo#215567

[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

The system encountered an error when users attempted to apply invalid filters on `binary fields` (e.g., `image_1024`). The error occurs when operators like 'is in' with empty string values ('') are used, as binary fields are stored As attachments only support existence checks.

**Steps to produce:-**
1. Add a filter like `[('image_1024', 'in', [])]` in the custom filter where the image exists(eg, Products) and save.
2. Error triggered.

**Error:-**

`Binary field 'Image 1024' stored in attachment: ignore image_1024 in [''] .`

**Solution:-**

- The `web` client's filter operator selection logic has been updated to restrict options for `binary` field types. Now, for binary fields, only the `is set` (`!= False`) and `is not set` (`= False`) operators will be available in the custom filter builder.

**Sentry - 6236134077**

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

Forward-Port-Of: odoo/odoo#221133
Forward-Port-Of: odoo/odoo#213608

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

Before this commit, the "Can edit message comment in chatter" test could fail intermittently. The test performs three edits on the same message, and due to the asynchronous nature of the bus (mock server > websocket > worker bus service > subscribers), bus notification are received later than rpc results.

The test was asserting composer content between edits, which is unnecessary and sensitive to race conditions.

For example:
- First edit is sent.
- Second edit is sent.
- First edit is received.
- Third edit opens the composer with outdated content.

This is unlikely to occur in practice. This commit resolves the issue by removing non essential composer assertions.

fixes runbot-227618

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#220812
Forward-Port-Of: odoo/odoo#220389

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

The system will crash with an error when we try to remove the field 'Delivery Address' from the invoice view while in 'fr company'.

**Steps to Produce:-**
- Install `l10n_fr` and `web_studio` with demo data.
- Switch to `FR Company`.
- Go to `Invoicing > Customers > Invoices`.
- Open any invoice > Toggle studio > Click on `Delivery Address` > and then click on `REMOVE FROM VIEW`.
- Observe the error.

**Error:-** `IndexError: list index out of range`

**Root Cause:-**
- At [1], the `_get_view` method unconditionally expects the `partner_shipping_id` field to be present in the invoice form view.
- It performs an `xpath` search for the field and immediately attempts to access the first element of the result list.

**Solution:-**
- Now, if the `partner_shipping_id` field exists in the view, then the logic proceeds as before. If it's not found, the code block is simply skipped.

[1]:
https://github.com/odoo/odoo/blob/044833804c9e10048ec10d7e982c98c4f33f4cf4/addons/l10n_fr_invoice_addr/models/account_move.py#L16

**sentry-6746543069**

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

Forward-Port-Of: odoo/odoo#218974

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

When the user removes the value of the start date and
selects the value again in the start date,
a traceback will appear

Steps to reproduce the error:
- Create one mo > Work orders > Add a line > Click on Open work order button
- In Time Tracking > Add a line > Remove the start date >
  Select the start date again > Apply

Traceback:
```
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
  File "odoo/http.py", line 2373, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1903, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1966, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1933, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2177, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 459, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 1007, in onchange
    record._apply_onchange_methods(field_name, result)
  File "odoo/models.py", line 7028, in _apply_onchange_methods
    res = method(self)
  File "addons/mrp/models/mrp_workcenter.py", line 448, in _date_start_changed
    self._loss_type_change()
  File "addons/mrp/models/mrp_workcenter.py", line 473, in _loss_type_change
    if self.workorder_id.duration > self.workorder_id.duration_expected:
  File "odoo/fields.py", line 1208, in __get__
    self.recompute(record)
  File "odoo/fields.py", line 1423, in recompute
    apply_except_missing(self.compute_value, recs)
  File "odoo/fields.py", line 1396, in apply_except_missing
    func(records)
  File "odoo/fields.py", line 1445, in compute_value
    records._compute_field_value(self)
  File "odoo/models.py", line 5037, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 101, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/saas-17.4/mrp_workorder_hr_account/models/mrp_workorder.py", line 62, in _compute_duration
    super()._compute_duration()
  File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 762, in _compute_duration
    wo.duration = wo.get_duration()
  File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 838, in get_duration
    duration += self._intervals_duration([(t.date_start, t.date_end or now, t) for t in times])
  File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 826, in _intervals_duration
    for date_start, date_stop, timer in Intervals(intervals):
  File "addons/resource/models/utils.py", line 124, in __init__
    for value, flag, recs in sorted(_boundaries(intervals, 'start', 'stop')):
  File "addons/resource/models/utils.py", line 51, in _boundaries
    if start < stop:
```

https://github.com/odoo/enterprise/blob/1f626176d28762683dc32ddbb351d994be894a71/mrp_workorder/models/mrp_workorder.py#L787 Here when "date_start" is empty,
It leads to the above traceback.

sentry-5679416830

Forward-Port-Of: odoo/enterprise#91259
Forward-Port-Of: odoo/enterprise#68014

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

When a `sign.request` record has `validity` as `False`, attempting to send a reminder via the `_cron_reminder` method leads to a crash.

**Steps to Reproduce:-**
1. Install the `Sign` module.
2. Navigate to the Sign section and click on `Upload PDF & Sign`
3. Upload any PDF document and add your signature, then click `Send`
4. In the new wizard, remove the value for `Valid Until` and enable the `reminder` option. Set the reminder to `every 1 day.`
5. When our scheduled action named `Sign: Send Mail Reminder` executes the following day, it will throw an error.

**Error:-**
`TypeError(''<' not supported between instances of 'bool' and 'datetime.date'') while evaluating 'model._cron_reminder()''`

**Root Cause:-**
The SQL query within the `_cron_reminder()` method retrieves all records where:
- The request is `active` and in the `sent` state.
- Either:
  - `validity < today` or
  - A reminder is due based on `last_reminder + reminder`.

The fetched records are then iterated through at [1].
 [1]
 https://github.com/odoo/enterprise/blob/ac4aeeea98dcf2fc7f06e6a3fabc55e256330e2c/sign/models/sign_request.py#L454

If `validity` is `False`, this comparison raises a `TypeError` because it is invalid to compare a `boolean` with `datetime.date`.

**Solution:-**
- A safety check was added before the comparison between `request.validity` and today's date, ensuring that `request.validity` exists.

Sentry-6727599497

Forward-Port-Of: odoo/enterprise#89646