## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear

The aim of this commit is to make the report behaves correctly when
facing a DB with a lot of vehicles and a lot of accounts by making the
query `group by` and `order by` more robust.

Context:
- 1 account and 1 vehicle share the same number for the id
- the account is tagged with disallowed expense tag
- 1 `account.move.line` without vehicle in that account
- 1 `account.move.line` with a vehicle (with a dna rate) in the same
  account

Before the commit:
- The computation is giving wrong result in the report: 2 `account.move.line`
  were aggregated together under the hierarchy of the account without vehicle
  and the vehicle doesn't appear in the report at all.
  cause: the `CASE WHEN` could return, for example `92` as a `vehicle_id` and
  then `92` as an `account_id` and thus have them regrouped together.

- 2 lines of the report were sharing the same "line_id" (the id given by
  report framework id, see method `_build_line_id`) which are used in a
  t-key property in an OWL loop resulting in a crash for the front-end.

After the commit:
- The 2 lines are aggregated seperatly: The line without `vehicle_id` is under
  the hierarchy of the account and the line with `vehicle_id` is under the
  hierachy of the concerned vehicle.
- The line doesn't share any line_id anymore

task-id: None (issue discovered in our own prod)

## [IMP] account_reports: ensure line_id is uniq in tests

Moved to https://github.com/odoo/enterprise/pull/66216

Forward-Port-Of: odoo/enterprise#64166

To reproduce the bug follow the instructions:
- Have pos and sales app installed
- Go to pos app setting and enable is a Restorant setting
- Back to the dashboard you should have a new shop called Restorant
- Go to the products from and create a product ('pencil' for instance), make it available in pos and in self-order and assign to it a category
- Add another product ('paper') with the same options in pos side and assign to it the same category, then add the first product ('pencil') to its optional product in sales section
- Back to pos dashboard open a sessing in Restorant shop then go back again to the dashboard
- Click on the tree dots on the top right of the Restorant shop block and click on the mobile view
- Create a new order adding 'paper' to the command then go to checkout

Now the optional product 'pencil' should be shown but it's unavailable.

A feature was added in Odoo 17.1 and newer for the availibility of the product on the point of sale app. It filter the product based on the availability hours of its categories. This brought changes to ProductCard component witch (you can check product_list_page) in pos_self_order modul for that. The thing is that these change wasn't made is pos_self_order_sale modul witch made the product always shown as unavailable.

opw-3977238

Forward-Port-Of: odoo/odoo#170119

Previously, when switching from an email template that overrides the email_from field to one that does not, the original email_from value was mistakenly passed as an argument. Consequently, emails were sent with the wrong sender, using the address from the template instead. Whereas, it is expected behavior that when a template does not specify any user, the current user's email address should be used as the sender.

[Changes introduced by this commit]
This commit addresses the issue by updating the sender email to the current user's email address when the template being updated to does not override the sender email field.

[Reproduce]
- Install -i contacts
- Log in as user U
- Create 2 Email templates that "Applies to" Contact (Settings/Technical/Email/Email Templates):
	- T1: set "From" field in "Email Configuration" tab (different than U's email)
	- T2: without set "From" field
- Go to a contact app, select any user
- Click "Send message" -> Expand "Full Composer"
- Select template T1 (with set email)
- Select template T2 (without set email) and Send
- BUG: email gets send with email from T1 (even tho we selected T2, without any email)

opw-3769188

# Encouraging discussion
I would like to encourage discussion on the fix, as I can imagine different approaches to this problem. (Like maybe instead we could not sent the `sent_from` argument from the fronted side and relay on the mechanism of default values). Any comments highly welcomed

Forward-Port-Of: odoo/odoo#170299
Forward-Port-Of: odoo/odoo#158000

There is currently an issue with the `report_stock_quantity` SQL view. When there is only 1 `stock_warehouse` in a given database and `pg_stats` for `stock_warehouse` is up-to-date, the query plan for scanning the `all_sm` cte (the `existing_sm` cte is always inlined) becomes extremely bad. That's because postgres somehow expects only 1 row returned by the `all_sm` cte whereas in real databases it can be closer to 500 000. This makes postgres plan a Nested Loop Join that has very bad performances in large databases.

Another weird side-effect of this is the production vs staging (duplicate) on Odoo.sh. Because stagings and duplicates don't necessarily have up-to-date statistics, you can have the same query being very slow on the production database and very fast on a staging. That's because in the absence of statistics for the stock_warehouse table, postgres does not make any particular assumption on the number of rows returned by the `all_sm` cte and therefore produces a more efficient plan.

This commit tries to change that by introducing a new small CTE that simply does a LEFT JOIN between `stock_location` and `stock_warehouse`. Because this CTE is referenced twice in the `existing_sm` CTE, it will be materialized by postgres, i.e. evaluated first before being saved in memory for further usage. Thanks to that, postgres knows the expected number of rows of the CTE and can better plan the outer query's execution.

#### speedup

Customer database with 17 000 products, 700 000 stock.moves, 97 locations and 1 stock_warehouse. Doing a simple GROUP BY query on `report_stock_quantity`: 5min -> 1s

##### dalibo

To understand the dalibo, currently there is a workaround for this issue. If we add (and archive) a new `stock_warehouse` and then analyze the table, postgres plans an efficient plan. My guess here is that with only 1 record postgres skews the plan, probably because it tries to shortcut parts of the query execution. When there are 2 or more warehouses it cannot do that anymore and simply relies on correct statistics to plan the execution. Another possibility would be that statistics for tables with 
only 1 row are badly used by postgres. In any case, the point of the new CTE is to match the 2 or more warehouses case when
postgres plans the scanning of the `all_sm` CTE.

- [1 warehouse, base case](https://explain.dalibo.com/plan/a8fagdgd2d20ae48)
- [2 warehouses, base case](https://explain.dalibo.com/plan/2d38fb9ef6df495g)
- [1 warehouse, new CTE case](https://explain.dalibo.com/plan/92e41053c9g0ce8d)


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

Forward-Port-Of: odoo/odoo#169401

A recent fix forbade the usage of partners from other companies on a SO (see 7be39d0b2157ec53e84c730a210868e4a4a1f8d9, and the comment on the original PR).

On the ecommerce, in some advanced multi-company & multi-website configuration, this led some customers to be unable to create a cart (add products to it), because their partner was restricted to another company.

It was previously possible, but led to other issues later on, e.g. during the post-processing of payment transactions linked to the cart.

Therefore, we consider it's still better to show a warning early on, but we prefer to replace the standard multi-company warning by a dedicated error message recommending the customer to have another account, or to contact the website administrator.

To solve the issue for a given customer, either he should have a separate account for the given company, or no company (ID) should be set on its partner record, so that it's shared between companies.


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

Forward-Port-Of: odoo/odoo#172433
Forward-Port-Of: odoo/odoo#172101

[FIX] stock.landed.cost: Use invoice date currency exchange rate for landed cost computation
    
Fixes an issue where the landed cost computation was based on the exchange rate of the accounting date instead of the invoice date, causing discrepancies in valuation and vendor bill. Now, the exchange rate of the invoice date is correctly utilized for accurate landed cost calculation.
    
To reproduce the issue:
    
1. Create a purchase order
2. Receive the product
3. Create a vendor bill for landed cost product in a different currency
4. Click on the "Create Landed Cost" button in the vendor bill

Error: The landed cost is computed using the exchange rate of the accounting date, while the total on the invoice is calculated using the invoice date's exchange rate. This results in a discrepancy between the bill price and the valuation.

The fix ensures that the exchange rate of the invoice date is used for computing the total for the landed cost.

opw-3862915

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

Forward-Port-Of: odoo/odoo#171039
Forward-Port-Of: odoo/odoo#165155