### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/9f2068549 [REL] 17.2.16 Task: 0
https://github.com/odoo/o-spreadsheet/commit/86adb37bf [FIX] charts: truncate labels by default Task: 3958962
https://github.com/odoo/o-spreadsheet/commit/de8b6b1a3 [PERF] evaluation: don't evaluate needlessly Task: 4036899
https://github.com/odoo/o-spreadsheet/commit/565dbdc9d [PERF] evaluation: invalidate spreading in batch Task: 4036899
https://github.com/odoo/o-spreadsheet/commit/d164e4215 [IMP] demo: add large demo data set for array formulas Task: 4036899
https://github.com/odoo/o-spreadsheet/commit/dd9f5a386 [FIX] functions: "*" doesn't match empty string Task: 4023057
https://github.com/odoo/o-spreadsheet/commit/62f4af81a [FIX] functions: match empty cells Task: 4023057
https://github.com/odoo/o-spreadsheet/commit/81381a425 [REV] chart: avoid useless chart updates Task: 4029016

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: Mehdi Rachico (mera) <mera@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>

Follow-up of https://github.com/odoo/odoo/pull/154349

PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from visitor's perspective.

The reason for shadow DOM is to use exactly same style and behaviour of livechat like in Discuss as internal users. The shadow DOM has to sustain its good working by itself, so it also needs to deploy some required main components like overlay container. In website, there's also an overlay container, and since they share the same stateful service (overlay_service), we do not want to display the overlay twice.

So PR above solved the issue by allowing to make overlay with a provided `rootId`, which when set it contains the `id` attribute of the root node of the overlay that has to manage the overlay. This allows to clearly determine which overlay container is responsible to display the appropriate overlay.

Code above was however buggy: it relies on `isVisible(overlay)`, whose computation requires `rootRef.el`. Refs' el are not determined on the 1st rendering of the overlay service. This is not a problem when the overlay container is 1st mounted without any overlay, but if it's being registered with some overlays, mounting the overlay container afterwards results in the non-showing of the overlay. The `rootRef` is important to find out the "global" root node id, i.e. the shadow DOM root id.

This commit fixes the issue by rendering again overlay container after mount when there are some pre-registered overlays.

## [FIX] project: let project user to set a project as favorite

Before this commit, since the project user cannot edit a project and a
recent fix (https://github.com/odoo/odoo/pull/168464) ensures the boolean_favorite widget is readonly is the field
is readonly or if the record is readonly then the project user can no
longer mark a project in favorite.

This commit overrides the standard widget `boolean_favorite` for project
to make sure the widget is always editable if the field is not in
readonly.

task-4041969

## [FIX] lunch: allow employee to save as favorite a product in lunch

Before this commit, the current user could have no access to lunch app
to add/edit product, etc. Since the user cannot edit `lunch.product`
model, he can no longer save as favorite a product since a recent bug
fix (https://github.com/odoo/odoo/pull/168464) to ensure the button is in readonly when the field or the record is
in readonly.

This commit makes sure the user can always save as favorite even if the
record is readonly for the user since the user just has to choose what
he would like to eat during lunch break and so he just needs to select
and save as favorite.

task-4041969

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

As of now, it is not possible to create a commercial move directly from the bank reconciliation widget. This commit aims to facilitate the workflow to create invoices or bills and reconcile them with existing bank statement lines.

Before this commit, if the user has a bank statement line for a unregistered commercial event, they have to:
1. Make a note of the amount, date and potentially a label
2. Navigate to Customers/Vendors > Invoices/Credit Notes/Bills/Refunds > New
3. Go back to the reconciliation widget (no breadcrumbs available)

After this commit, the user will be able to create a move through a button in the bank reconciliation widget. The move is pre-filled with relevant information, such as amount, date and partner (if available). The user can return to the bank reconciliation widget through the breadcrumbs, and proceed to validate the created and added move.

This commit:
- Modifies behaviour of function actionSelectRecoModel to support the creation of moves.
- Modifies function _js_action_select_reconcile_model to continue supporting journal entries as previously, but also the creation of moves.
- Adds the function _action_redirect_to_move_button to create the relevant move and action leading to the move.
- Modifies _js_action_restore_st_line_data to add the created move to the reconciliation widget.
- Adds flag 'move_aml' to bank reconciliation widget line model.

task-3768742

*: account_reports, l10n_lu_reports

Description of the issue/feature this commit addresses:

The current behavior of footnotes makes it impossible to have multiple
footnotes by company by line. Also, when annoting a line in a report for a
certain period, and changing the period of the data shown by the reports, the
annotation stays. This leads to footnotes being irrelevant or
give false pieces of information.

This commit transforms footnotes into annotations which are much more
flexible and are a more powerful tool for the users.

---

Desired behavior after the commit is merged :

This commit brings a rework to the annotations' system by moving adding
and changing some features they bring.

1 - The annotation now disposes of a "date" field which is set to the value
of the "date_to" period of the data currently shown on the report. This
value is then used during the computation of which annotations have to be
shown and which have not to be shown so that only annotations for
the current period appear.

2 - When clicking on the "Annotate" button on a line that already has an
annotation, previous behavior was the opening of a dialog with the content
of the current annotation which gave the possibility to edit it.
Now, if a line has already one visible annotation, that button is not shown
anymore. The line name has a little comment bubble next to it which opens the
"annotation popover". Inside the popover, the user can read mulitple pieces of
information regarding each annotation of the line which are : its text content,
its author, the date it has been written at and the date it targets. The user
can also edit and delete each of these annotation or add more via a "New"
button.

3 - The footnote section at the bottom of a report with at least one footnote
has been removed as the content of the annotation is now available directly on
the annotated line and it made no sense to leave it.

4 - In the xlsx export, an additional column has been added to
keep the annotations during the export. There is one column by line
regardless to the number of annotations the line has and in a case in
which a line would have multiple annotations, each of them would be
numbered and split by a return character.

5 - In the PDF export, the rendering is now able to show multiple
annotations on a single line.

6 - Journal Report and Followup Report used to have a footnote rendering
process for the pdf export but since those Reports don't offer the
possibility to annotate lines, thoses process have been removed.

Adding this improvement, annotations are much more flexible
and can bring real value to reports.

---

task-3301125

## Issue:
- When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number.

## Steps To Reproduce:
- Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity.
- In the barcode app, adjust the inventory by adding the created product and then save the changes.
- Click on the small pen icon to modify the product's details.
- Observe that when adding the quantities with decimal values, they get rounded up to the nearest whole number.

## Solution:
- In the `_increment` function, when the initial `value` is not a decimal (it does not contain a '.'), the fraction variable is not set, and the rounding defaults to 0. It's important to note that this issue does not occur when the `value` is a decimal, as the split function operates correctly.
- To resolve this issue, instead of relying on the number of digits after the '.' in the `value`, we set the precision based on what is defined in the 'decimal.precision' model. This approach not only addresses the current issue but also resolves the underlying problem initially discussed in this PR https://github.com/odoo/enterprise/pull/53378

opw-3896929

Forward-Port-Of: odoo/enterprise#65619
Forward-Port-Of: odoo/enterprise#62505

Steps to reproduce
-------------------
- create a commission plan with:
    product category: "All"
    rate: R capped: True
    max commission: >>>
- create a partner level with the created commission plan
- create a partner with the created partner level

- create a product in the correct category with price P
- create a quotation template with the created product

- create a sale order with the partner as referrer
- add the quotation template (the product is added automatically)
- confirm
- create the invoice, confirm it and register the payment

At this moment, a purchase order is created (the commission) If we repeat these steps with a new sale order,
the amount of the purchase order will increase as expected.

- add a quotation template on the commission plan (in the rules)
- repeat the creation of a sale order.

No commission is added (purchase order line).

Cause:
------
We have no template when calling `_match_rules`.
However, our plan has a default template.
The result is that no rules are found.

Solution:
---------
Fallback on the sale order's template
if it is not a subscription.

opw-3933323

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