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

**Current Behavior:**

Manual discounts are not retained when adding optional products to the order.

**Steps to Reproduce:**

1) Install the sale_subscription module.
2) Create a subscription with a recurring plan.
3) Add a product to the Optional Products section. 
4) Manually set a discount on the optional product. 
5) Click on the Add to Order Lines (cart) button.
6) A new SOL is created.

**Issue:**

The newly created SOL does not retain the manually set discount.

**Cause:**

- When the user clicks the Add to Order Lines button, the `add_option_to_order` method is triggered.
This method creates a new sale order line (SOL) using values from `_get_values_to_add_to_order`.

- In the current implementation, this method is overridden for subscription orders to exclude the 
discount value from the returned data.

https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/sale_subscription/models/sale_order_option.py#L17-L21

- This forces a recomputation of the discount based on pricelist rules, 
which unintentionally removes any manually set discount.

**Solution:**

- Only remove the discount value from the returned data and trigger recomputation 
if there is no manual discount.

- This ensures that any user-defined discount is preserved when creating the order line.

opw-4840735

Forward-Port-Of: odoo/enterprise#90748
Forward-Port-Of: odoo/enterprise#89381

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

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

**Steps to reproduce**:
1. Install `helpdesk` only
2. Create a second company and configure a distinct logo for both the default and new companies.
3. Create a Helpdesk ticket under the new company.
4. Use the 'Share Ticket' (gear icon) feature to generate a portal link.
5. Open the link in an incognito window or a different browser (where no user is logged in).
6. Observe the logo shown in the portal navigation bar.

**Observed behavior**:
The portal incorrectly displays the logo and branding of the default/main company, even when the Helpdesk ticket belongs to a different company.

**Issue**:
When no portal user is logged in, the `res_company` used in the portal rendering context defaults to the system’s primary company (`env.company`). The template expects `res_company` to be explicitly set to reflect correct branding. See:
https://github.com/odoo/odoo/blob/880954ebfc1106411b7f7a7d60aee05dfae60893/odoo/addons/base/models/ir_qweb.py#L781

**Solution**:
Explicitly pass `ticket_sudo.company_id` as `res_company` in the portal view context to ensure correct company branding is used.

opw-4855281

Forward-Port-Of: odoo/enterprise#90600

<b>Steps to produce :</b>

1) Install 10n_de_reports and switch to the German company 
2) Create a journal entry from accounting with a credit and debit 
3) Now update the credit and debit to a different value. 4) Post the journal
5) Go to "Accounting / Reporting / Audit Reports / General Ledger" 
6) Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv"

<b>Issue:</b>
The line for the created journal entry has a price_total of 
the previous balance even after updating the credit and debit values.

<b>Cause:</b>
When the user updates the 'debit' and 'credit' values for an `aml`, 
The `price_totals` value remains unchanged as it is not dependent on `balance`.

So, it will show the previous value in the report line 
because we are taking the abs(aml.price_total) from the report data.

<b>Solution:</b>
We can add an extra check of the move type so that it will fall back to the else block, 
where the line_amount will take a value by calculating taxes from `aml.tax_ids.compute_all`.

opw-4707567

Forward-Port-Of: odoo/enterprise#85436
Forward-Port-Of: odoo/enterprise#83777

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

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

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

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

**Steps to reproduce**:
1. Install `helpdesk` only
2. Create a second company and configure a distinct logo for both the default and new companies.
3. Create a Helpdesk ticket under the new company.
4. Use the 'Share Ticket' (gear icon) feature to generate a portal link.
5. Open the link in an incognito window or a different browser (where no user is logged in).
6. Observe the logo shown in the portal navigation bar.

**Observed behavior**:
The portal incorrectly displays the logo and branding of the default/main company, even when the Helpdesk ticket belongs to a different company.

**Issue**:
When no portal user is logged in, the `res_company` used in the portal rendering context defaults to the system’s primary company (`env.company`). The template expects `res_company` to be explicitly set to reflect correct branding. See:
https://github.com/odoo/odoo/blob/880954ebfc1106411b7f7a7d60aee05dfae60893/odoo/addons/base/models/ir_qweb.py#L781

**Solution**:
Explicitly pass `ticket_sudo.company_id` as `res_company` in the portal view context to ensure correct company branding is used.

opw-4855281

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

`test_parse_inline_template` has never been run "officially" since it's not in a module's test directory, which is where the built-in test harness looks things up.

Miraculously it actually worked still if one managed to get it run (via some other test harness), however with #212315 it's now broken:

- #212315 unconditionally looks up the `test_tags` during `__init__`
- way back when test tags were added in b356b190338e3ee032b9e3a7f670f76468965006, a default value for test tags was only set on classes defined somewhere within the `odoo.addons` namespace, this was kept on all subsequent updates (even after the `module` was removed from the test tags and moved to a separate attribute)

As a result, when running `test_parse_inline_template` the initialisation of each test now fails with an `AttributeError` right in the `__init__`.

Can't be arsed to move the test to a place where it's run, and clearly nobody's cared in the last 4 years.

Forward-Port-Of: odoo/odoo#220832
Forward-Port-Of: odoo/odoo#220768