Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the record in the main view. Because of that, the chatter for that subtask is not displayed.

This commit opens the form view in the main view instead of opening it inside a form view dialog to be able to display the chatter of the subtask selected.

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

1. Install project and go to project app.
2. Create a project A.
3. Add a task inside the project A
4. Add a subtask inside the new task created in step 3
5. Open the form view of the task created in step 3 in mobile
6. Click on the kanban record contained the subtask created in step 4

Expected behavior:
-----------------

The chatter should be displayed in the form view of that subtask to be able to communicate with the customer.

Current behavior:
----------------

Since the form view of the subtask selected is opened inside a form view dialog the chatter for that subtask is not displayed.

task-4278273

Forward-Port-Of: odoo/odoo#220814
Forward-Port-Of: odoo/odoo#200178

**Problem:**
when updating quantity of a product in company A
from a user logged in on company B the svl
are created with wrong values and standard price
is incorrectly updated

**Steps to reproduce:**
- check two companies on the top right of the screen (comp A and comp B)
- create a storable product with a avco category
- make sure that the cost method of the category is avco both when logged in with company A and B
(the cost method is company dependent)
- while logged in with comp A create, confirm, receive and validate a PO for a quantity of 1 and a unit price of 100
- do the same while logged in with comp B but with a unit price of 10
- open the product form (cost should be 100 or 10 depending on the company)
- while logged in on comp B click on the 'on hand' smart button
- update from 1 to 2 the on hand quantity in the WH of comp A
- switch to comp A and come back to prodcut form

**Current behavior:**
the standard price is 55.
additionaly, when opening inventory/reporting/valuation and chossing the product we see that the svl created has a value of 55

**Expected behavior:**
standard price should stay at 100 and the svl
should be created with a value of 100

**Cause of the issue:**
Product_price_udpate_before_done calls get_price_unit to compute the new standard price.
https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L345 Inside get_price_unit, because the move has no unit_price we use self.product_id.standard_price which will take the standard price of comp B
https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L59

opw-4852096

Forward-Port-Of: odoo/odoo#219549
Forward-Port-Of: odoo/odoo#217524

[FIX] html_builder: handle clear button in BuilderDateTimePicker
When the `clear` button was used three consecutive times in the
BuilderDateTimePicker, the input field would remain empty instead of
reverting to its previous value.
This occurred because `useDomState` wasn't being triggered due to no
state change.

Additionally, this fix ensures that the input field now updates
immediately upon using the `clear` button, eliminating the need for
subsequent validation or clicking outside the DateTimePicker.

Steps to reproduce:
- Drop `s_countdown` snippet.
- Open DateTimePicker with the "Due Date" option.
- Click the clear button, then apply.
- Repeat the previous step two more times (for a total of three times).
- The input field remains empty instead of displaying the current date.

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

[FIX] html_builder, website: reintroduce null default for options
This commit restores the previous behavior where
`data-customize-website-variable="null"` was used to set a null default
value for website options, ensuring that SCSS correctly applies its own
default styles to elements. This functionality was lost during the
website refactor [1].

Additionally, the `BuilderNumberInput` now defaults to 0, aligning
with the previous default in `UnitUserValueWidget`.

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4b596d77d [REL] 18.4.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/8e43be7a8 [FIX] header_sizes_ui: preserve row sizes on insert and move ops [Task: 4885579](https://www.odoo.com/odoo/2328/tasks/4885579)
https://github.com/odoo/o-spreadsheet/commit/76a224263 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710)
https://github.com/odoo/o-spreadsheet/commit/a45061c1d [FIX] auto_complete: remove toggle button for data validation [Task: 4854464](https://www.odoo.com/odoo/2328/tasks/4854464)
https://github.com/odoo/o-spreadsheet/commit/30a11dd57 [FIX] Composer: Remove formatting when pasting external content [Task: 4910559](https://www.odoo.com/odoo/2328/tasks/4910559)
https://github.com/odoo/o-spreadsheet/commit/71ec7d472 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369)
https://github.com/odoo/o-spreadsheet/commit/cea21be36 [FIX] spreadsheet_pivot: empty row when number added to char field [Task: 4878778](https://www.odoo.com/odoo/2328/tasks/4878778)

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>

This commit improves the code of the `remove` plugin:

- Rename the `on_remove_handlers` and `after_remove_handlers` resources as `on_will_remove_handlers` and `on_removed_handlers` respectively, to be more consistent.

- Adds a `is_unremovable_selector` resource in order to use it to get the selectors of the elements that are unremovable. It allows to have the resources in the different option plugins, instead of duplicating these selectors in multiple files.

- Merge back the behaviors of `removeElementAndUpdateContainers` and `removeElement` as it was not correct to split them and in order to have only one main `removeElement` function. Its goal was to replace the old `remove_snippet` event, and it was clearly not used everywhere.

- Remove the use of the `remove` plugin where only the JS element `remove` function was needed. We know if a given case needs to activate the parents/siblings and there are other ways to activate them anyway.

- Use the `remove` plugin when this time it was necessary (e.g. when a "Table of Content" is empty).

- Clean the code.

task-4367641

*: website_crm_partner_assign, website_customer, website_membership,
   website_partner

Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the goal of properly computing `can_publish` without sudo... but it missed using it properly. The related test was passing... because it was also not properly written.

This commit fixes the issue by using the context key at the proper places. However, this limits the fix to pages and partners at the moment as the bug is not critical in stable versions.

It however fixes a test while run in no-demo (which becomes the norm in later versions). With that in mind, this also changes the view (by *adding* things to be as stable as possible) to go around the use of the context key and make new databases properly compute `can_publish` for all records type. Old databases will keep the old behavior for some models, which leads to displaying the "Publish" button but not be able to use it (access right warning).

[1]: https://github.com/odoo/odoo/commit/d47d824fc484e1592fc4af8d0d378d5a4a579550
[2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da
[3]: https://github.com/odoo/odoo/commit/436a167dedb2ed008bcb88e8a4eccafc8d20812c

Related to runbot-161791

Forward-Port-Of: odoo/odoo#220424
Forward-Port-Of: odoo/odoo#219389

**Current behavior:**
Creating a purchase order in a foreign currency and billing the
product prior to reception will produce 2 issues:
A) The bill line for the product will only make a conversion of
1 single unit of the product with the defined currency exchange
rate, making the amount on the line incorrect when qty > 1

B) When the receipt is finally validated, there will be an
unwanted exchange difference on the journal items generated due
to asymmetrical rounding for the bill AMLs and receipt valuation
AMLs

**Expected behavior:**
Correct bill line currency amounts and symmetric rounding.

**Steps to reproduce:**
1. Set the company currenct to IQD, make a product invoiced on
ordered qty, for sake of example set cost to 500 IQD

2. Create a currency exchange record to USD with a company rate
of `0.00756`

3. Create a PO for 13 of the product created in step 1, with a
discount of 1%

4. Confirm the PO and create the bill -> post it

* Issue A) look at invoice line, see only 1 unit in the
converted currency amount is accounted for by the `balance`

5) Receive the product -> look at the journal items generated
and see that there is a diff of 0.185 IQD

**Cause of the issue:**
A) commit: 90158f6 added a method to try and calculate an AML
balance from its purchase line values, but mistakenly is using
`qty_received` instead of `qty_to_invoice` which explains why
this issue only presents for the bill-before-receipt flow

B) commit: 9f046d5 is using `round=False` context for
`AccountTax.compute_all()` when the expected key is `round_base`

**Fix:**
A) Replace `qty_received or 1` with `qty_to_invoice`
* Also make the test added in 90158f6 more robust

B) Add `round_base=False` alongside the `round` key (not
removing as that existing one could have become expected in this
context)

opw-4689170

Forward-Port-Of: odoo/odoo#220323
Forward-Port-Of: odoo/odoo#205850

Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.

Purpose: The user should be able to send templates they created in any allowed companies.

Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access

[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown

``` 
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
    value = env.cache.get(record, self)
  File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'

During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.

Records: BE Company CoA (id=2)
User: Marc Demo (id=6)

This restriction is due to the following rules:
- company rule employee

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/> 
```


opw-4706828

Forward-Port-Of: odoo/enterprise#85402

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

Issue:
The VAT return journal is not created when installing `account_reports` (or `accountant`) after `account`, when the CoA is already created.

Solution:
Create it in the post init hook.

Note that we force the creation of the journal only when `accountant` is installed because it would make noise for invoicing only in most cases. It will still be created automatically when needed.

Also, make the code a little bit more robust:
* instead of mixing "default misc journal" and vat return journal logic, just use one logic
* the function `_get_tax_closing_journal` could return multiple journals but was always used as if it could only contain one
* the function `_get_tax_closing_journal` could not return any journal. Instead, we now create the journal or look for a value on the parent companies if any.
* Manage `show_on_dashboard` in `create` also by using an inverse field. Even if in normal cases the journal will always be created after the company the thus set through `write`, it is not impossible to set it in `create` when creating company branches. Since it is always done when setting the journal on the company, there is no need to set the field in the post-init hook.

Forward-Port-Of: odoo/enterprise#91126

When Debug requests is enable on the whatsapp business account and
user replies with the file, a traceback will appear.

Steps to reproduce the error:
- Install ``whatsapp`` and ``contacts``
- Create a whatsapp business account > Enable Debug requests
- Create a contact > Add a phone number > send whatsapp message with any whatsapp template
- Now reply with the file(ex. pdf or image) in message from the contact's whatsapp.
- Traceback in terminal

Traceback:
``ValueError: A string literal cannot contain NUL (0x00) characters.``

https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/models/whatsapp_account.py#L166
Here, ``message`` contains NUL (0x00) characters because user replies with
the file, value for the ``message`` comes from the below response.

response: https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/tools/whatsapp_api.py#L49-L57

Here, ``res.text`` contains NUL (0x00) characters.
So, it will lead to the above traceback.

sentry-6314521165

Forward-Port-Of: odoo/enterprise#91055
Forward-Port-Of: odoo/enterprise#83274

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#219907
Forward-Port-Of: odoo/odoo#214300

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d30327ce0 [REL] 18.3.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/270b64f5a [FIX] header_sizes_ui: preserve row sizes on insert and move ops [Task: 4885579](https://www.odoo.com/odoo/2328/tasks/4885579)
https://github.com/odoo/o-spreadsheet/commit/65a3252b4 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710)
https://github.com/odoo/o-spreadsheet/commit/056ce29b9 [FIX] GridComposer: Recompute composer position if we change edited cell [Task: 4879186](https://www.odoo.com/odoo/2328/tasks/4879186)
https://github.com/odoo/o-spreadsheet/commit/994301a64 [FIX] auto_complete: remove toggle button for data validation [Task: 4854464](https://www.odoo.com/odoo/2328/tasks/4854464)
https://github.com/odoo/o-spreadsheet/commit/bcf0f3ebe [FIX] Composer: Remove formatting when pasting external content [Task: 4910559](https://www.odoo.com/odoo/2328/tasks/4910559)
https://github.com/odoo/o-spreadsheet/commit/b9c2fe323 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369)
https://github.com/odoo/o-spreadsheet/commit/5626d48fe [FIX] spreadsheet_pivot: empty row when number added to char field [Task: 4878778](https://www.odoo.com/odoo/2328/tasks/4878778)

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. Install Accounting and l10n_sa_edi
2. Switch to a SA company
3. Go to Accounting > Configuration > Journals > Sales > ZATCA > Re-onboard
4. Create or duplicate a customer invoice > Confirm
5. Click on blue banner "Process Now"
6. Log in as a non-admin user (e.g., Marc Demo) and Switch to a SA company
7. Go to invoice > Open Same invoice > Click to "PRINT"

**Issue:**
- A traceback is raised when trying to access the attachment linked to the ZATCA document.

**Cause:**
- Since commit https://github.com/odoo/odoo/commit/44a4cdb3944a4b722dcfbca5e2947a4372b8501d, access to  EDI document's attachment (`attachment_id`) is restricted to users 
belonging to "Role > Administrator" group (`group_system`).
- This was introduced as part of changes from  Task [#4341594](https://www.odoo.com/odoo/project/49/tasks/4341594)
 As a result, non-admin users (even with accounting rights) are unable to access the attachment causing a traceback.

**Solution:**
- Apply `compute_sudo`to field `l10n_sa_qr_code_str` to bypass the restrictive access rights.
  So even if for any case any other field causes issues in the future, compute_sudo will take care of it

**opw-4923399**

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

Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the record in the main view. Because of that, the chatter for that subtask is not displayed.

This commit opens the form view in the main view instead of opening it inside a form view dialog to be able to display the chatter of the subtask selected.

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

1. Install project and go to project app.
2. Create a project A.
3. Add a task inside the project A
4. Add a subtask inside the new task created in step 3
5. Open the form view of the task created in step 3 in mobile
6. Click on the kanban record contained the subtask created in step 4

Expected behavior:
-----------------

The chatter should be displayed in the form view of that subtask to be able to communicate with the customer.

Current behavior:
----------------

Since the form view of the subtask selected is opened inside a form view dialog the chatter for that subtask is not displayed.

task-4278273

Forward-Port-Of: odoo/odoo#220569
Forward-Port-Of: odoo/odoo#200178

**Issue**
Using a Greek letter in the journal's sequence prefix causes a traceback error when confirming an invoice

**Steps to Reproduce**
1. Install the Accounting module
2. Navigate to Accounting > Configuration > Journals
3. Open the Sales journal
4. Under the Advanced Settings tab, set the communication standard to "European"
5. Set the sequence prefix to include Greek letters (e.g., "TΠY")
6. Create and confirm a new invoice
7. Observe the traceback error

**Root Cause**
The prefix is used in calculating the `check_digits` via a base-36 to base-10 conversion. This conversion fails for Greek characters, which are not valid in base-36, leading to an exception

**Fix**
Greek letters in the prefix are transliterated to their Latin equivalents before performing the checksum calculation, ensuring compatibility with the base-36 conversion logic

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

Forward-Port-Of: odoo/odoo#212169

Before this PR:
When creating invoices/orders for foreign customers that don't have states defined in their country, both **account.move** and **sale.order** models would incorrectly assign the company's Indian state as the place of supply. This happened because the fallback logic would always use **move.company_id.state_id** without checking if the partner was actually Indian. As a result, foreign customers would be treated as Indian customers in GST calculations, leading to incorrect tax treatment and compliance issues.

After this PR:
Both models now correctly identify foreign customers by checking the partner's country first, before falling back to state-based logic. Foreign customers without states are now properly assigned the foreign state reference (**l10n_in.state_in_oc**) instead of the Indian company's state. This ensures accurate GST treatment where foreign customers are correctly identified as overseas transactions.

Task-4900697

Forward-Port-Of: odoo/odoo#220717
Forward-Port-Of: odoo/odoo#216220

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

https://github.com/odoo/odoo/commit/ef4c1350df10c186efec79b1414306e325707549 introduced a new exception `ServerActionWithWarningsError`: https://github.com/odoo/odoo/blob/851c46923332aa13c56fbce3a5ed3c5d37a70c92/odoo/addons/base/models/ir_actions.py#L486-L488
This was not registered as an error_dialog. This led to the frontend displaying the entire traceback instead of an error dialog similar to `UserError` when a `ServerActionWithWarningsError` is raised. This commit fixes it by correctly registering the error in `error_dialog` registry category so a more user friendly dialog is displayed with the error contents.

Thanks @brboi for helping with the fix

### Current behavior before PR:

A traceback error is thrown when a `ServerActionWithWarningsError` is raised. Example:
<img width="1896" height="904" alt="image" src="https://github.com/user-attachments/assets/0bfee329-e6c5-4652-a2ac-d41b763e2bdb" />


Video reproducing it: https://drive.google.com/file/d/1C_aE0d_9bP27f388dB1NJLeWHBpsM7AW/view?usp=drive_link (credits: gavb-odoo)

### Desired behavior after PR is merged:

An error dialog similar to UserError which is easier to understand is displayed

<img width="1906" height="799" alt="image" src="https://github.com/user-attachments/assets/d57c5cab-14f2-4f39-9f0c-b8099e8b0089" />


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

opw-4885670

Forward-Port-Of: odoo/odoo#219977

Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.

Purpose: The user should be able to send templates they created in any allowed companies.

Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access

[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown

``` 
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
    value = env.cache.get(record, self)
  File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'

During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.

Records: BE Company CoA (id=2)
User: Marc Demo (id=6)

This restriction is due to the following rules:
- company rule employee

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/> 
```


opw-4706828

Forward-Port-Of: odoo/enterprise#85402

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

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#90998
Forward-Port-Of: odoo/enterprise#76779

This PR introduces some reporting features to the VoIP module.

It introduces several improvements to the VoIP
module, including the addition of a new button for viewing
call history in user settings and the implementation of
a detailed call view with enhanced data fields such as
duration, day of the week, and time slot. The call model
now computes the duration and time slot based on the start
date, and the user interface has been updated to include new
menu items for better navigation. Additionally, tests have
been added to ensure the correct computation of time slots
during different seasons.


Also, it adds an expand button to the recent calls tab in the voip
wizard so that the user can open the full list view of the recent calls.
Also, it adds some predefined filters to the `voip.call` views.

Also, it introduces a new `SearchBar` component to enhance the user
experience in the softphone interface. The search bar is now included in
the address book, agenda, history, and keypad tabs, allowing users to
filter entries more efficiently.

Additionally, the `onInputSearch` functionality has been debounced in the
agenda to improve performance during searches. The history tab now
features an expandable button for viewing recent calls, further
streamlining navigation.

Currently an error occurs when we try to merge data in deduplication.

Steps to replicate:
- Go to: Data Cleaning > Configuration > Deduplication.
- Open any Deduplication Rules > Deduplicate > select any record (Make sure at least one record is available in list view).
- Click `Merge` on top left.

Error:
`ValueError: invalid literal for int() with base 10: 'NaN'`

The error because of a recent [refactor](https://github.com/odoo/odoo/pull/205486) where the data of a `many2one` will be an object rather than an array. (task-[3547961](https://www.odoo.com/odoo/project/49/tasks/3547961))

In `saas-18.3`, `record.data.group_id` (many2one field) was an array, so the line [1] worked perfectly. But starting in `saas-18.4`, after the change, the value became an object instead of an array. Because of that, `record.data.group_id[0]` is now `undefined`, and `parseInt()` returns NaN, which causes the `int()` on line [2] to throw a `ValueError`.

[1] - https://github.com/odoo/enterprise/blob/7d020d73762a17386cae4b68c15a5d59a51fb480/data_cleaning/static/src/views/data_merge_list_view.js#L108

[2] - https://github.com/odoo/enterprise/blob/7d020d73762a17386cae4b68c15a5d59a51fb480/data_cleaning/models/data_merge_group.py#L113


The lines that returns object is [this](https://github.com/odoo/odoo/blob/564348a5172ea98b38c903686c21d007d0e57b48/addons/web/static/src/model/relational_model/utils.js#L517-L523).

This commit solves the problem by accessing the ID using `.id` instead.

sentry-6739344848

Forward-Port-Of: odoo/enterprise#90157

Issue:
The VAT return journal is not created when installing `account_reports` (or `accountant`) after `account`, when the CoA is already created.

Solution:
Create it in the post init hook.

Note that we force the creation of the journal only when `accountant` is installed because it would make noise for invoicing only in most cases. It will still be created automatically when needed.

Also, make the code a little bit more robust:
* instead of mixing "default misc journal" and vat return journal logic, just use one logic
* the function `_get_tax_closing_journal` could return multiple journals but was always used as if it could only contain one
* the function `_get_tax_closing_journal` could not return any journal. Instead, we now create the journal or look for a value on the parent companies if any.
* Manage `show_on_dashboard` in `create` also by using an inverse field. Even if in normal cases the journal will always be created after the company the thus set through `write`, it is not impossible to set it in `create` when creating company branches. Since it is always done when setting the journal on the company, there is no need to set the field in the post-init hook.

Forward-Port-Of: odoo/enterprise#91126

Issue
=====
When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed.

How to reproduce
================
- Enable multi-locations and package;
- Create an empty package, two locations and two products;
- Create a delivery in the Barcode app;
- Scan the first location then the first product;
- Scan the second location then the second product;
- Scan the empty package -> The package is rightly assigned as the result package for both lines, but the source location of the first product was update for the last scanned source location.

Cause of the issue
==================
When a source location was previously scanned, when a line is updated (`updateLine`), we update the line's source location. Usually, that's the wanted behavior but in this case, we don't want to the source location of already processed lines when we scan a destination package.

Solution
========
When calling `updateLine` from `_assignEmptyPackage`, give a key in the parameters to not update the source location.

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

Forward-Port-Of: odoo/enterprise#90713
Forward-Port-Of: odoo/enterprise#89142

Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.

Purpose: The user should be able to send templates they created in any allowed companies.

Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access

[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown

``` 
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
    value = env.cache.get(record, self)
  File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'

During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.

Records: BE Company CoA (id=2)
User: Marc Demo (id=6)

This restriction is due to the following rules:
- company rule employee

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/> 
```


opw-4706828

Forward-Port-Of: odoo/enterprise#85402

Issue
-----
Images on the purchase portal are displayed in their original size instead, making it a visual mess.

Steps to reproduce
-----
- Create a product with a large image
- Create a purchase for the product
- Click the cog wheel > Share
- Open the link in a new tab (with no active session, eg private window)

--> The image is way too big

Cause
-----
Images are now converted to Webp:
https://github.com/odoo/odoo/commit/1a978183001e0503104285f4bd5bed983beb0efb

The problem is that Webp images cannot be resized through the Python backend:
https://github.com/odoo/odoo/blob/0c6622294b7117ec5eb1cbf8a9270636b2dd807f/odoo/tools/image.py#L81-L83

However, the product model has multiple sizes for the image:
https://github.com/odoo/odoo/blob/3ddf2bcdf16b5b43db4c4abe2cdbc4384cf683cc/addons/product/models/product_product.py#L91-L94

What we can do is load the smallest possible image and then use styling to limit the display size.

The 48px comes from the hardcoded values in
https://github.com/odoo/odoo/blob/0c6622294b7117ec5eb1cbf8a9270636b2dd807f/addons/purchase/controllers/portal.py#L99

This fix will no longer be needed when (if) Webp images get resized in backend.

Comparison
-----
Left is before, right is after fix.
![image](https://github.com/user-attachments/assets/fac07fa2-5ab7-404c-80ad-fd57a6f55ed3)

Image used
-----
![opw_4625113](https://github.com/user-attachments/assets/cd3e6ea6-1a9a-4ce5-aa71-44f400c612e1)

-----
Ticket:
opw-4625113

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

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/0f3b11a81 [REL] 18.0.38 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5e9706fa6 [FIX] header_sizes_ui: preserve row sizes on insert and move ops [Task: 4885579](https://www.odoo.com/odoo/2328/tasks/4885579)
https://github.com/odoo/o-spreadsheet/commit/e1c4e6255 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710)
https://github.com/odoo/o-spreadsheet/commit/17cd60e8f [FIX] GridComposer: Recompute composer position if we change edited cell [Task: 4879186](https://www.odoo.com/odoo/2328/tasks/4879186)
https://github.com/odoo/o-spreadsheet/commit/ec8a90d51 [FIX] auto_complete: remove toggle button for data validation [Task: 4854464](https://www.odoo.com/odoo/2328/tasks/4854464)
https://github.com/odoo/o-spreadsheet/commit/c693c6ee0 [FIX] Composer: Remove formatting when pasting external content [Task: 4910559](https://www.odoo.com/odoo/2328/tasks/4910559)
https://github.com/odoo/o-spreadsheet/commit/ba683b429 [FIX] spreadsheet_pivot: empty row when number added to char field [Task: 4878778](https://www.odoo.com/odoo/2328/tasks/4878778)
https://github.com/odoo/o-spreadsheet/commit/41c774ac1 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369)

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>

**Current behavior:**
Modifying the "Product Price" global precision and purchasing some product in a foreign currency sometimes leads to problematic SVL creation, which will make a posted vendor bill unable to be reset to draft when it logically should be permitted.

**Expected behavior:**
No SVL, can reset vendor bill.

**Steps to reproduce:**
1. Activate a foreign currency, set the "Product Price" precision from 2 -> 3, make an exchange rate to the foreign currency with a rate: `0.2710027100271003`

2. Make a product with avg costing, real time valuation, with a standard price = `0.875`

3. Create a purchase order in the foreign currency for the avco product:
* `price_unit: 0.237`
* `product_qty: 5500`

4. Confirm -> receive -> create invoice -> post
* Can't reset the bill to draft
* There is an additional SVL that shouldn't have been generated

**Cause of the issue:**
There will be a negligible rounding diff between the price units of the journal item and SVL created on reception. When the invoice is posted, this will captured and when multiplied by a large enough invoicing qty, will create a large enough value to trigger creation of pdiff SVL.

**Fix:**
Zero out the price unit difference if it is functionally equivalent to zero when rounded according to the maximally precise "precision record" involved in the sequence, that is:

A) The bill currency
B) The SVL currency
C) The "Product Price" global precision value

opw-4873246

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

When a combo contained a product that had variant with type 'no_variant' and 'always', if you added the product to the cart the product configuration popup would not open. Also, in the combo you can only select product_product and not product_template, so the product configuration popup should not propose the variant linked to the 'always' type, as you already selected a product template in the combo configuration popup.

Steps to reproduce:
-------------------
* Create a product attribute PA1 with type 'no_variant' and 2 values V1 and V2
* Create a product attribute PA2 with type 'always' and 2 values V3 and V4
* Create a product template PT1 with PA1 and PA2
* Create a combo choice PC1 with the 2 variants of PT1
* Create a combo product CP1 with PC1
* Open PoS and add CP1 to the cart
* The combo configurator popup opens, click on the version with V2
> Observation: The product configurator popup does not open
> Second fix: The product configurator allows you to select the
  variant linked to the 'always' type, which is not correct as you already selected it through the combo configurator popup

Why the fix:
------------
The first fix just make sure that the product configuration popup opens when it is necessary.
The second fix filters the variants proposed in the product configuration popup to only show the variants that are not linked to the 'always' type. But this only happens when we do it from the combo configuration popup.

opw-4719258

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

Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.

Purpose: The user should be able to send templates they created in any allowed companies.

Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access

[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown

``` 
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
    value = env.cache.get(record, self)
  File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'

During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.

Records: BE Company CoA (id=2)
User: Marc Demo (id=6)

This restriction is due to the following rules:
- company rule employee

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/> 
```


opw-4706828

Forward-Port-Of: odoo/enterprise#85402

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