Currently an error occurs when the user import the product record.

Steps to Reproduce (to avoid step just try to import this [File](https://github.com/user-attachments/files/20360727/Product.product.template.1.xlsx)) :

 - Install the `account` module.
 - Go to Products > switch to `List View`, select a `product`, and click `Export` under the Actions.
 - In the Available Fields, search for `Sales Taxes` or `Purchase Taxes`, select either one, and then click `Export`.
 - In the Products, click Actions > Import Records, and upload the file that was recently exported.
 - Click import.

`TypeError: Domain() invalid argument type for domain: None`

This error occurs when a user imports a product template record and the system calls name_search to resolve tax_id values. When no domain is passed, it defaults to None, causing a TypeError.

This commit ensures that when the system calls name_search to resolve tax_id values without a domain, an empty domain ([(1, '=', 1)]) is used instead to prevent the error.

sentry-6616172972


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

When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt:
- An Exchange diff account move would be created, and the Stock Input Account would not be balanced

This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rate journal entry is created, and a discrepancy in the Stock Input Account balance is introduced.

When the bill is posted before the receipt is validated, we want the receipt to have the value of the bill, and there is no reason to have only the balance or the amount in currency from the bill, so we can take both of them.


https://github.com/user-attachments/assets/c6dc5e72-8f5b-4c0f-99fa-c5e98a9574ff


## How to reproduce:
- Install stock_account,purchase
- Create product P:
    * Valued in AVCO automated.
    * Control Policy to 'On ordered quantities'
- Add currency rates for the EUR currency:
    * 2.0 on the 2025-01-01
    * 2.1 today
- Create and Confirm a new purchase for 1 unit of P and a price of 100 Euros
- Create the Bill:
    * Set the bill's accounting date & bill date to the 2025-01-01
    * Confirm the bill
          => Amount in Currency: 100 Euros - Balance: $50 USD - Rate used: 2.0
- Go back to the PO and receive the product.
          => Amount in Currency: 105 Euros - Balance: $50 USD - Rate used: 2.1
- Check the created Journal Entries:
          => Currency exchange rate difference: $2.38
          => (105 - 100) / 2.1

OPW-4631348

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

Forward-Port-Of: odoo/odoo#210538
Forward-Port-Of: odoo/odoo#209118

### Steps to reproduce:
	1. Create a portal user.
	2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view
	3. Now, add the portal user as a follower on a task.
	4. Change the state of a task to execute an automation rule.
	5. Email will be received by a portal user but it will not be visible on the messaging history on the portal.

### Cause:
This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages.

### Fix:
Checking if the server action that is being run is sending an email we will
set the state of the 'mail.message' as 'auto_comment' -introduced in https://github.com/odoo/odoo/pull/94018/commits/d1dd307555ac78841384d1158de5a0a7787370db - and add 'auto_comment'
to the domain of the field website_message_id which is for the messages
shown to the portal user in his view

P.S. LNA confirmed that we need to show it to the portal user.

opw-4459754

Forward-Port-Of: odoo/odoo#210807
Forward-Port-Of: odoo/odoo#194401

Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts.
Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions.

Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail.

We revert the recent commit https://github.com/odoo/odoo/commit/818602363a751bf1777b57261e1accafb45e7439 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions.

The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the operators "today", "next", "last" will not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported.

Forward-Port-Of: odoo/odoo#210576
Forward-Port-Of: odoo/odoo#208876

Issue
=====
In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`:

```python
self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [
    {'lot_id': lot_product_b[0].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[0].id, 'quantity': 0, 'value': 1.5},
    {'lot_id': lot_product_b[1].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[1].id, 'quantity': 0, 'value': 1.5},
    {'lot_id': lot_product_a[0].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[0].id, 'quantity': 0, 'value': 1},
    {'lot_id': lot_product_a[1].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[1].id, 'quantity': 0, 'value': 1},
    {'lot_id': lot_product_a[2].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[2].id, 'quantity': 0, 'value': 1},
])
```
This issue is sometime the records order is not the expected one.

Cause of the issue
==================

By doing `recordset.sorted('product_id')`, it will sort the records by compare their `product_id` records, using the python built-in `sorted`. The built-in `sorted` function simply check if record A is lower than record B, using the < operation. But in Odoo, comparing two recordsets is equal than comparing their ids as a `set`:
```python
def __lt__(self, other):
    try:
        if self._name == other._name:
            return set(self._ids) < set(other._ids)
    except AttributeError:
        pass
    return NotImplemented
```
In python, the comparaison between two sets compares is a set is a subset of the other one, which means than:
```python
{1} < {2}     # is false
{1} < {2, 1}  # is true
```
So, comparing SVLs by their product won't sort them by their product's id. If we want to do that, we have to explicitly do it by passing a function as the `sorted` `key` argument.

For more information, see:
-https://docs.python.org/3/library/functions.html#sorted -https://docs.python.org/3/reference/expressions.html#comparisons

runbot-build-error: 99086

Forward-Port-Of: odoo/odoo#210514

Description of the issue/feature this PR addresses:
The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually available due to rounding. For example in the following case:
Product-A is made via Kit-BoM from 2 Units of Product-B. There are 3 units of Product-B in stock. The precision of the "Unit" UoM, used for Product-A, is set to 1 (only integer amounts). The actual amount of units available is 1.5, this is rounded as Half-Up to 2 Units. This is misleading, since only one unit of Product-A could be shipped.

Current behavior before PR:
For Kit-BoM Products, the quantities in _compute_quantities_dict() are all rounded with HALF-UP, potentially rounding up and claiming a higher availability than actually supported.

Desired behavior after PR is merged:
_compute_quantities_dict() rounds down to ensure it doesn't over-promise.



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

Forward-Port-Of: odoo/odoo#209317
Forward-Port-Of: odoo/odoo#208374

This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221.

This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.

The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.

Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0

Forward-Port-Of: odoo/odoo#210859
Forward-Port-Of: odoo/odoo#209832

When manually changing the `discount_date` field to null in an invoice related to a customer with an Early price discount payment term, the customer will face a type error on the website when accessing their invoices.

**Steps to reproduce:**

* Install the accountant module
* Create a new invoice for the current user as a customer (e.g., Mitchel Admin).
* Set `2/7 Net 30` in payment terms and add any product.
* Go to Journal Items and make Discount Date visible if not already visible.
* Under the account field `121000 Account Receivable` remove the discount date
  and confirm the invoice.
* Open portal View (/my) and click on Your Invoices >>> Error occurs.

`TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'`

**Solution:**
We use if else blocks to check if `discount_date` exists for the `days_left calculation`; if it exists,
do the calculation as usual if `discount_date` is in future. Otherwise, set `days_left` to zero and continue the function as usual.

Sentry-6395559503

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

Forward-Port-Of: odoo/odoo#205306

1. Display email of the recipients if email is given otherwise
fallback to `Unnamed`.

  Steps to reproduce 
  1. Create a contact with no name.
  2. Open the chatter from any document.
  3. Try to send a message to the contact without name.

  -> Tag without name will be shown

  From [Commit 1], we added a possibility to show partner's information or enter
  missing email address with [Commit 2]. In the case when partner didn't have
  name set, tags's text was shown blank.

  After this commit, tags of widget many2many_tags_email having no name will
  show email if given otherwise "Unnamed".

2. Account
   Account send invoice wizard will allow partners without email as the opened
   wizard will ask for the email.

3. SMS
  If sending sms fails because of account unregistered, we will redirect the user
  on click of the red SMS button to the IAP SMS account if user can access,
  otherwise the normal popover is shown as usual.

[Commit 1]: https://github.com/odoo/odoo/commit/abdb7654e463c7b20b7e0d16e0b9cb76863cbdeb
[Commit 2]: https://github.com/odoo/odoo/commit/2bbf118e60d793bea98078810a282fe45e896403

Task-4711346

Forward-Port-Of: odoo/odoo#205349

This commit fixes the historical unwanted change that was introduced with commit https://github.com/odoo/odoo/commit/2b3c8e6ca9777f6264ecb3d1510dd292ed30ab9f Which modifies the report name for india and replace them with the Journal name. Till saas-18.2 It was okay for indian localisation but following the changes made in PR https://github.com/odoo/odoo/pull/195279 and https://github.com/odoo/odoo/pull/189664

Which changes the journal name and takes standard xml inheritance to py method. After the above mentioned PRs. It displays unwanted Report i.e. In case of Invoice it displays the `Sales INV/2025-26/01` which is unwanted. In this commit we adapt the standard `account` report name for `l10n_in` which should be removed in the `master` only one case should be adapted for India which is whenever an invoice having tax we should print it
as **Tax Invoice**

opw-4781816



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

Forward-Port-Of: odoo/odoo#209579

**Description of the issue/feature this PR addresses:**
- The contact-us form allows task creation without a project (project_id = None).
These tasks are assigned to odoobot, have no followers, and no project, making
them inaccessible due to ACL restrictions. 

**steps to reproduce**
1. Install website_form_project.
2. Edit the contact-us form submit button.
3. Set action to 'Create a task' and select 'None' for the project.
4. Save and submit the form.

**Observation**
- Tasks created under such configuration are hidden in the UI and trigger access
errors when trying to open them.

![access error](https://github.com/user-attachments/assets/e5688152-d78b-4628-a0bd-d9f58e2ca442)

Desired behavior after PR is merged:
- Making the project field required, the created tasks will now be accessible/visible

[opw-4664601](https://www.odoo.com/odoo/project/49/tasks/4664601)

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

Forward-Port-Of: odoo/odoo#210109
Forward-Port-Of: odoo/odoo#207871

## Issue:

When converting a lead to an opportunity, a wizard
(`crm.lead2opportunity.partner`) is shown. This allows merging
duplicated leads.

However, if the most recently created lead is selected as the primary,
the wizard record may be deleted unexpectedly. This usually goes
unnoticed in the UI, as the wizard disappears after the operation.

The issue becomes critical when overriding the conversion flow via a
custom module or in future changes to the core logic. In those cases,
the deletion of the wizard can lead to empty recordsets and errors.

#### Affected versions: 16.0 and later.

## Explanation

The `crm.lead2opportunity.partner` model has a `Many2one` field
`lead_id` that is being deleting on cascade which is the default
for m2o fields on transient models.

During lead conversion, action_apply() calls _action_merge() or
_action_convert(). In _action_merge(), non-primary leads are
unlinked. If the primary lead is the last created one, it differs
from the one referenced by the wizard. This causes lead_id to be
unset, triggering the cascade and deleting the wizard.

## Impact:

If a custom module overrides action_apply() or _action_merge() and
calls super() first, it may operate on an empty recordset, leading
to failures when trying to access data or call methods.

## To reproduce:

With debugger:

- Set a breakpoint on the unlink call inside _action_merge
- After unlink, calling self.exists() on the wizard will return an empty recordset

With a custom module:

- Override action_apply() or _action_merge()
- Call super() first
- Try to merge leads and select the most recent one as primary
- The wizard record will be deleted before your custom logic executes, and will raise a "Record does not exist or has been deleted."

OPW-4773172

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

Forward-Port-Of: odoo/odoo#209795

Prior to this commit, if you had been testing out adding a product to your cart on your website, and then later decided to change your default company, you would no longer be able to access your website. This was due to an access rights error when reading the sale order representing the cart, to load in the top navbar.

This commit fixes this by canceling any abandoned carts when switching default companies. The choice to cancel the order outright was recommended by the PO, BOJE. However, RDE believes that there is a deeper problem in `website_sale` if this one is showing up like this. 

Before 18.2, we could change the default company on a user after adding a product to our cart and then still access our website, making use of the existing cart. Again, per BOJE's request, we are handling this issue by canceling the cart outright as this is a _very_ niche case.

This massive commit e3a3c58 to 18.2 changed a lot of `website_sale` code and could be worth a deeper look by the e-commerce team.

Forward-Port-Of: odoo/odoo#210669

This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval.

Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:00 and 05:00 respecively, up to a 1-hour difference for daylight savings time. Now suppose that the paysliip for this work entry only goes up to that following morning. Instead of using the local times of 18:00 and 01:00, the payslip would use the UTC times of 22:00 and 05:00, which would only count 2 of those hours instead of 6.

This is resolved by converting the UTC times to local before using them to clamp the work entries to the payslip interval.

opw-4790119

Forward-Port-Of: odoo/enterprise#85967
Forward-Port-Of: odoo/enterprise#85548

### Steps to reproduce:
	1. Create a portal user.
	2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view
	3. Now, add the portal user as a follower on a task.
	4. Change the state of a task to execute an automation rule.
	5. Email will be received by a portal user but it will not be visible on the messaging history on the portal.

### Cause:
This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages.

### Fix:
Checking if the server action that is being run is sending an email we will set the state of the 'mail.message' as 'auto_comment' and add 'auto_comment' to the domain of the field website_message_id which is for the messages shown to the portal user in his view

opw-4459754

Forward-Port-Of: odoo/enterprise#85969
Forward-Port-Of: odoo/enterprise#82352

…vailability

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The `preparation_time` (`Security Time`) field is used at the sale order line creation to modify the `reservation_begin` value: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L447-L453 In particular, the `preparation_time` of the product creates a difference between the `order_id.rental_start_date` and the `reservation_begin`. This is porblematic since the `rental_start_date` is used to generate the dates of the deliveries taken into account by the forecast:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L354-L362 but the quantity considered as rented does not and is purely based on the `reservation_begin` of the line:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/product_product.py#L113-L117 In particular, the qunaities are not yet accounted ithe stock forecast by the `virtual_available` value of the product:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L129-L132 But will incorrectly be found and read by the rental forecast: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L133-L140

opw-4552760

Forward-Port-Of: odoo/enterprise#85949

Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error:

```
Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')
at ActivityListPopoverItem.template
```

This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly on returned RPCs. The code of VOIP returns activity data with a custom formatter, which omits `persona` that is important for the good templating of an activity in Chatter otherwise there's the crash above.

A recent PR [1] attempted to fix this issue, but the syntax for Store was wrong: it used the syntax for an item in field list (e.g. in `_to_store_defaults`) instead of pure store data from a specific record. This bad use of Store.One() resulted in actually returning `False`.

[1]: https://github.com/odoo/enterprise/pull/84970

opw-4586756

Forward-Port-Of: odoo/enterprise#85907

Steps to reproduce:
(thanks to TBS for investigating + writing the test)

1. Have a MX company with Quadrum or SwSapien
2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN`
3. Create a USD invoice for `13220.00 USD` and send CFDI
4. Reconcile transaction and invoice
5. Click "Update payments" on the invoice => CRP20211

Looks like it comes from this rounding difference

Rate is computed by odoo using
`305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`

PAC verify the amount paid using
`13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN`

Solution:
There is no solution by adapting the rate:
- quadrum restricts the rate to 6 decimals;
- rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`.

So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly
`round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`.

In tests, both Quadrum and SwSapien seem to accept this.

We don't perform the modification for Solucion Factible (the other PAC).

opw-4222310

Forward-Port-Of: odoo/enterprise#85602
Forward-Port-Of: odoo/enterprise#83499