*: website, survey

Since commit [1] the calendar icon in input group date is not clickable
anymore and does not open the date picker anymore.

This commit simply restore that by auto discovering the calendar icon,
should the input group follow this common pattern:
```xml
<div class="input-group date">
    <input
        type="text"
        class="form-control datetimepicker-input"
    />
    <div class="input-group-text"><i class="fa fa-calendar"></i></div>
</div>
```

This seems enough to cover all cases detected in the website apps:
- <details><summary>The two datepicker in /my/opportunity when editing the lead to adapt
  the "Expected Closing" and "Next Activity Date" fields</summary>
  
  ![image](https://github.com/odoo/odoo/assets/30048408/0fc57676-112b-4ee9-a74e-c89634a3b509)
  
  </details>
- <details><summary>The website form date(time) input</summary>

  ![image](https://github.com/odoo/odoo/assets/30048408/4426e8b4-ce3c-4c5b-9fba-f315dd84c502)
  
  </details>
- <details><summary>The ecommerce renting product rental period inputs ("from" and "to"
  dates)  </summary>

  ![image](https://github.com/odoo/odoo/assets/30048408/f9d63ff7-448c-4909-b9dc-ec129b1a6670)
  
  </details>
- <details><summary>The `o_website_sale_daterange_picker` snippet</summary>

  ![image](https://github.com/odoo/odoo/assets/30048408/74003996-75ee-441e-89f1-ed58e4fb00c0)
  
  </details>
- <details><summary>The survey date fields</summary>

  ![image](https://github.com/odoo/odoo/assets/30048408/120c3942-9c6d-4c0e-aaa6-8255e425d717)
  
  </details>
- ..maybe other places..

Should there be cases needing this feature for calendar icons which are
not following the suggested input group layout, they can do it this way:
```diff
-        this.call("datetime_picker", "create", {
+        const picker = this.call("datetime_picker", "create", {
            // ...
        }).enable();
+        this.el.parentNode.querySelector(".input-group-text").addEventListener("click", picker.openPicker(0));
```

[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628

Forward-Port-Of: odoo/odoo#161466

There is an issue with some of the images having `loading="lazy"`
attribute. Those are incorrectly marked as edited (dirty).

This is because those images do receive a `min-height` style attribute
change when the widget is started thanks to [1]:
- On page load, the images receive `style.minHeight = '1px';`
- Once the images have been load a few moment later, this `min-height`
  is removed / restored to its initial value. If there were no initial
  value and if there is no other style attribute on the image, it will
  leave the image with an empty `style` attribute.

But commit [2] made it so those empty attribute (class/style) are
removed from the DOM as part of the sanitizing process.

This commit does 2 things:
- It disable the wysiwyg observer while commit [1] `min-height`
  operations are being one.
- It prevent commit [1] to leave images with an empty `style` attribute.

Note:
- it was detected on our Odoo.com/app/expenses where a single word
  change in a section flags 27 unrelated images as o_dirty and
  ultimately triggers 27 save rpc call instead of only one.
- commit [2] was merged in Odoo 16 but only seems to lead to this bug in
  Odoo 16.4. Something else is probably involved in the o_dirty addition
  process. It doesn't seems worth it investigating deeper to find
  exactly what as this commit changes are things that probably should
  have been done initially anyway.

[1]: https://github.com/odoo/odoo/commit/e9ef21b6cd5ae58322fa9102f9f34f06835f0485
[2]: https://github.com/odoo/odoo/commit/5962b9ee2e90cc04ede1c1f9bbb519869db77f71

Forward-Port-Of: odoo/odoo#164742
Forward-Port-Of: odoo/odoo#150535

Currently, when a portal user creates a task in a project, the stage is set to none, which create a new stage in the pipe.

Steps to reproduce:
-------------------
* Connect to the db as a portal user
* Navigate to **Projects**
* Select any
* Create a new task
* Refresh the page
> Observation: The task is created in the None stage

Why the fix:
------------
The `stage_id` of the task created by the portal user is set to false here:
https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L928-L929

Prior to https://github.com/odoo/odoo/commit/fb88a7448c75fdcbe1d9c3664402a1dea2733326, the `project_id` was computed as `project_id = vals.get('project_id') or self.env.context.get('default_project_id')`. Now it is defined as follows:
https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L894

If `vals.get('project_id')` is false/none, the task is still created using `self.env.context.get('default_project_id')` for portal users.
  https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L955-L958
  https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L813-L820

We recompute `project_id` using the context value. We do that after the following piece of code so that, in the case of subtasks, they are not displayed in the project.
https://github.com/odoo/odoo/blob/8780f8d9799eed7188d6577c6bb2690df598196e/addons/project/models/project_task.py#L916-L929

This aloows to keep the writing cascade on the field `project_id`
https://github.com/odoo/odoo/blob/8780f8d9799eed7188d6577c6bb2690df598196e/addons/project/models/project_task.py#L1007-L1009

opw-3873983

Forward-Port-Of: odoo/odoo#164201

This traceback occurs when the user clicks on the `employee` smart button.

To reproduce this issue:-

1) Install `Employees`, `contacts` without demo data 
2) Enter into `multi-company` environment by creating  a new company 
3) Now create a new `employee` with company as new company and
  related `user` in the `Hr settings` as `Administrator`
4) Now switch to `single company` environment by disabling new company
5) click on the `employee` smart button from `contact` module for the
  `Administrator` record
6) A traceback occurs

Error:- 
```
ValueError: Expected singleton: hr.employee(1, 3)
```

Because after the commit `{1 }` from `saas-17.1` 
when we have multiple records for a record in `multi-companies` 
and shift to `single company`, the other company records are also `accessible`.

Because of that it leads to the above traceback when trying to access `id` from `self.employee_ids`

https://github.com/odoo/odoo/blob/4f9b67938032a8b253d930a70acd2283b30ecda6/addons/hr/models/res_partner.py#L30-L36

[1] https://github.com/odoo/odoo/pull/159210/commits/3c8e4496702a07d1f6e989882f69c3b93b82f663

After applying this commit will resolve this issue by filtering 
the `employee_ids` based on the current company record `id`

sentry-5289238474

Forward-Port-Of: odoo/odoo#164294

Steps to reproduce:
-------------------
- create a new time off type (with approval and allocation)
- create an accrual plan with 1 day (monthly on the 1 day of the month)
- create two allocations with the type, one regular (X days) and one accrual (Y days)
- take a time off of Z days with the condition: Z < X + Y
- run `Time Off: Cancel invalid leaves` scheduled action

Issue:
------
The time off is canceled with the following message:
```
The time off has been canceled: the accruated amount is
insufficient for that duration.
```

Cause:
------
To delete the leave with the cron `_cancel_invalid_leaves`:

[A] The leave must be:
- between today and today + 31 days
- have at least an allocation of type `accrual`.

[B] We need an `exceeding_duration`:
`additional_leaves_duration > latest_remaining`
<=> `additional_leaves_duration > latest_remaining`
<=> `additional_leaves_duration > virtual_remaining - date_accrual_bonus + latest_accrual_bonus`
<=> `leave.number_of_days > virtual_remaining - date_accrual_bonus + latest_accrual_bonus`
<=> `leave.number_of_days > SUM_ALLOC(virtual_remaining_leaves) - SUM_ALLOC(accrual_bonus) + SUM_ALLOC(_get_future_leaves_on(leave.date_from))`
<=> `leave.number_of_days > SUM_ALLOC(virtual_remaining_leaves)` (simplify the use case)

As we have a regular allocation, the following logic will be used:
```py
leave_type_data[allocation]['virtual_remaining_leaves'] -= allocated_time
```

The result is that the condition cancelling the leave will be respected when it should not.

Solution:
---------
Move the logical block which adds the leave to `to_recheck_leaves` if an `accrual` type allocation is detected,
so as not to make changes with regular allocations.

opw-3869889

Forward-Port-Of: odoo/odoo#164979
Forward-Port-Of: odoo/odoo#164556

## Description
The `onchange` triggered when changing the `allow_billable` setting of a large long living project with a high number of associated timesheets can take a quite a while.
After profiling, a significant portion of the bottleneck was coming from *frequent* calls to the `__hash__` function, called when initializing a new `set` in
https://github.com/odoo/odoo/blob/cf9aa2a14761a417c641243fc0b2be121c387b46/odoo/models.py#L6838
Left Heavy profile:
![profile_onchange_billable_after_orm_patch](https://github.com/odoo/odoo/assets/111067497/fb6bc313-478a-44e1-9684-a7dc266171ae)


## Improvements
- Invariant hoisting: the `set(self._ids)` can be lifted out of the lambda scope capture, passing only a reference to a local variable for all callsite of the lambda. This prevents the re-computation of `set(self._ids)` for each record in `cache_records` due to the linear iteration done by `filtered`.
- `not isdisjoint` vs `intersection`: the lambda is checking for the existence of an intersection between 2 sets. But in python the `&` or `intersection` method *construct* a new instance of a `set`. In our case we don't care about the resulting intersection, only about the existence of it. We can improve the situation by inverting the logic using `not isdisjoint`, as `isdisjoint` is simpler internal implementation and doesn't construct any new set, it just checks for disjunction.
  - CPython `intersection`:
https://github.com/python/cpython/blob/333c7dccd87c637d0b15cf81f9bbec28e39664fd/Objects/setobject.c#L1179-L1256
  - CPython `isdisjoint`: https://github.com/python/cpython/blob/333c7dccd87c637d0b15cf81f9bbec28e39664fd/Objects/setobject.c#L1338-L1373 

  A local small `timeit` benchmark showed +- 25% faster performance in favor of `not isdisjoint`.

## Benchmark
On a staging database (saas-17.1, blindly backported), the `onchange` triggered by setting a project `allow_billable` from `True` -> `False`, with 70k tasks, and 25k associated timesheets.

|         | Before               | After               | Speed Up    |
|---------|----------------------|---------------------|-------------|
| Timings | 246.66 sec (4.1 min) | 66.83 sec (1.1 min) | 3.6x faster |

## Reference
task-3872314

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

Forward-Port-Of: odoo/odoo#165138