Original PR description

# Owl DateTimePicker (community) This PR introduces a date picker OWL component meant to handle the following use-cases: - date picker - date & time picker - date range picker - date & time range…

# Owl DateTimePicker (community)

This PR introduces a date picker OWL component meant to handle the
following use-cases:
- date picker
- date & time picker
- date range picker
- date & time range picker

Basically, this component is the union of the two previous third-party
libraries handling these cases: TempusDominus and DateRangePicker.

## New components introduced:

* The main addition of this commit is the `DateTimePicker` itself which
handles the display and interactions of the calendar and time pickers.
> see @web/core/datetime/datetime_picker

* The picker can then be coupled to an input using the
`useDateTimePicker` hook. The purpose of this hook is to handle events
on a given input element and syncronize its value to a date picker it
will spawn in a popover.
> see @web/core/datetime/datetime_hook

* Lastly, a simple `DateTimeInput` component will render an input and
call the hook mentioned above to handle it. This component is
effectively replacing the previous DatePicker and DateTimePicker
components (note that it does not handle range values).
> see @web/core/datetime/datetime_input

## Date range declarations in views

Another noticeable change of this commit is the definition of daterange
fields in views:

- Previously, the arch would have to define both fields
and bind them via their options, while also adding an arrow between
inputs or other forms of connection.

- In the new implementation, only the start date field must be declared,
and a date range can be spawned by providing an `end_date_field` in its
options.

Example:
```xml
<field
    name="start_datetime"
    widget="daterange"
    options="{'end_date_field': 'end_datetime'}"
/>
```

## ⚠️ Added limitations

- this new way of declaring date ranges means that templates have been
revised to declare one field tag instead of two. This means that list
views using date ranges have lost the ability to be sorted on their end
date fields.

> Justification: the current use cases have been reviewed and it has
been decided that it was not needed to sort on the end date on the
affected list views.

> Workaround: drop the date range and declare both fields as simple date
pickers (i.e. without the end_date_field option).


- all modifiers applied to a field using a date range will be copied and
applied to the end date field. There is no way to define modifiers
specific to one field or the other.

> Justification: there was no use case where one of the two fields
needed specific modifiers.

> Workaround: same as the previous point: split the range into 2 simple
date picker fields.


## Additional notes:

- the `widget="daterange"` is not mandatory in form views, but is required
in list views because only fields with explicit widgets will not be
rendered as simple <span> elements. The date range feature will be
available as soon as an end_date_field is specified.

- as the end date field is not explicitly defined in the view anymore,
any modifier depending on it need to have it defined as invisible
somewhere in the arch.

## Links
- Enterprise PR: https://github.com/odoo/enterprise/pull/38569
- Documentation PR: https://github.com/odoo/documentation/pull/4330
- Task ID: [3121497](https://www.odoo.com/web#id=3121497&cids=1&menu_id=4720&action=333&active_id=133&model=project.task&view_type=form)

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

Purpose
=======
Improve UI in various modules

Specifications
===========
event{_booth}{_crm}, website_event{_meet}{_track}{_track_live}
-------------------------------------------------------------------------------------------
- The reporting fields, the chat room and the participant count
of the meeting room form should not be showed while the record
is not created.
- Rewording on event track "Button appears" and "Color" field.
- Remove unnecessary helpers in event track form.
- Remove "Wishlisted By" stat button when the count is equal to 0.
- Add many2one widget avatar on lead rule "Saleperson" field and
event track "Responsible" field.
- Add placeholders in event booth form view, event location
tree view, event tags categories form view and event stages
form view.

mail, mass_mailing_sms, phone validation:
---------------------------------------------------------------
- Add sample data in the mass_mailing_sms blacklist phone
numbers tree view.
- Update the mass_mailing_sms demo data so that, instead of
the sms being stuck due to a lack of credits, they are
all sent.
- Swap the mass_mailing_sms list view with the kanban view
so that the list view is the main one like in Email Marketing.
- Rename the reset mail template confirm button from "Proceed"
to "Reset Template" to make the action more explicit.

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

# Owl DateTimePicker (enterprise) This PR introduces a date picker OWL component meant to handle the following use-cases: - date picker - date & time picker - date range picker - date & time range…

# Owl DateTimePicker (enterprise)

This PR introduces a date picker OWL component meant to handle the
following use-cases:
- date picker
- date & time picker
- date range picker
- date & time range picker

Basically, this component is the union of the two previous third-party
libraries handling these cases: TempusDominus and DateRangePicker.

## New components introduced:

* The main addition of this commit is the `DateTimePicker` itself which
handles the display and interactions of the calendar and time pickers.
> see @web/core/datetime/datetime_picker

* The picker can then be coupled to an input using the
`useDateTimePicker` hook. The purpose of this hook is to handle events
on a given input element and syncronize its value to a date picker it
will spawn in a popover.
> see @web/core/datetime/datetime_hook

* Lastly, a simple `DateTimeInput` component will render an input and
call the hook mentioned above to handle it. This component is
effectively replacing the previous DatePicker and DateTimePicker
components (note that it does not handle range values).
> see @web/core/datetime/datetime_input

## Date range declarations in views

Another noticeable change of this commit is the definition of daterange
fields in views:

- Previously, the arch would have to define both fields
and bind them via their options, while also adding an arrow between
inputs or other forms of connection.

- In the new implementation, only the start date field must be declared,
and a date range can be spawned by providing an `end_date_field` in its
options.

Example:
```xml
<field
    name="start_datetime"
    widget="daterange"
    options="{'end_date_field': 'end_datetime'}"
/>
```

## ⚠️ Added limitations

- this new way of declaring date ranges means that templates have been
revised to declare one field tag instead of two. This means that list
views using date ranges have lost the ability to be sorted on their end
date fields.

> Justification: the current use cases have been reviewed and it has
been decided that it was not needed to sort on the end date on the
affected list views.

> Workaround: drop the date range and declare both fields as simple date
pickers (i.e. without the end_date_field option).


- all modifiers applied to a field using a date range will be copied and
applied to the end date field. There is no way to define modifiers
specific to one field or the other.

> Justification: there was no use case where one of the two fields
needed specific modifiers.

> Workaround: same as the previous point: split the range into 2 simple
date picker fields.


## Additional notes:

- the `widget="daterange"` is not mandatory in form views, but is required
in list views because only fields with explicit widgets will not be
rendered as simple <span> elements. The date range feature will be
available as soon as an end_date_field is specified.

- as the end date field is not explicitly defined in the view anymore,
any modifier depending on it need to have it defined as invisible
somewhere in the arch.

## Links
- Community PR: https://github.com/odoo/odoo/pull/112171
- Documentation PR: https://github.com/odoo/documentation/pull/4330
- Task ID: [3121497](https://www.odoo.com/web#id=3121497&cids=1&menu_id=4720&action=333&active_id=133&model=project.task&view_type=form)

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