Purpose
=======
The goal of this task is to help timesheets users to have a better control of the app, and to encourage them to record their timesheets by introducing tips and a monthly ranking system that ranks users accordingly to their billing rate or to their total recorded time.

Changes introduced
==================
- Added a billing rate and a total time indicator.
    - These informations are displayed on the "My Timesheets" grid/list/kanban view once the setting "Billing Rate Target" is activated in the settings.
    - The billing rate formula is as such : billable_time / billable_time_target * 100. The billable time target is unique to each employee, and can be changed in the employee's HR settings.
    - Once the "Billing Rate Target" setting is activated, a billing rate target can be set for the company. If the current employee's billing rate falls below the company's billing rate target, the billing rate indicator is displayed in red, else it is be displayed in green.
    - If the current employee's total recorded time does not correspond to the theoretical total recorded time according to their working hours, then the total time indicator is displayed in red.
    - Timeoff entries are excluded from the ranking calculation.
- Added a leaderboard on the My Timesheets grid/list/kanban views.
    - This leaderboard is displayed once the setting "Billing Rate Leaderboard" is activated in the settings.
    - It displays the top three employees of the selected month for the grid view, and the top three employees of the current month for the list/kanban view. If the current user is in the leaderboard, then only the 2 first employees are displayed along with the current employee.
    - When clicking on the leaderboard, a Dialog is opened showing more details about the leaderboard.
    - The leaderboard disappears once the timer starts.
- Added a leaderboard dialog window.
    - This dialog window displays many informations about the ranked employees, such as their total billable time, their billable time target, their total recorded time and their billing rate.
    - Three buttons allows the user to change the selected month, and display the leaderboard for the selected month.
    - There are two types of ranking criteria : rank by billing rate, and rank by total recorded time. The criteria can be changed through the dialog view, and changes the leaderboard's ranking.
- Added "Timesheets Tips".
    - These tips are fully editable by timesheets managers, and a random one is displayed on the right of the leaderboard dialog window.

Technical details
=================

sale_timesheet_enterprise
---------
- Added a SQL request in `res.company`. This request fetches the employees id, their name, their billable time, their billable time target, their total recorded time, their recorded time as of today, and their billing rate, for the selected company in the selected period of time. 
- Added two different groups `group_timesheet_leaderboard_show_rates` and `group_use_timesheet_leaderboard`. The former allows users to see the billing rate and the total time indicators, and the latter allows users to see the leaderboard.
- Added two different settings in `res.company`: group_timesheet_leaderboard_show_rates` and `group_use_timesheet_leaderboard`. The former gives the `group_timesheet_leaderboard_show_rates` group to all employees, and the latter gives the `group_use_timesheet_leaderboard` group to all employees.
- Added a `TimesheetLeaderboard` component. This component is added on the `TimerGridRenderer`, the `TimesheetTimerListRenderer` and the `TimesheetTimerKanbanRenderer` views, and is visible if the user has the `group_timesheet_leaderboard_show_rates` group. Note that only the billing rate and total time indicators are visible if the user only has this group ; for the leaderboard to be visible, the user has to have the `group_use_timesheet_leaderboard` group.
- Added a `Many2OneAvatarRankField` component. This component displays the rank of the employee, and its profile picture.
- Added a `TimesheetLeaderboardDialog` view. This Dialog can be opened by clicking the leaderboard.
- Added `hr.timesheet.tip` model to store tips, and a `_get_random_tip` method to fetch a random tip from the table.
- Added field `billing_rate_target` on res.company model. This field can be edited through the settings, and is constrained to stay between 0 and 100 included.
- Added field `billable_time_target` on hr.employee model. This field can be edited through the employee's HR Settings, and is constrained to stay positive.
- Changed the `TimesheetTimerHeader` component to separate it from the div containing it, so that the leaderboard can be placed onto it without depending from this component.
- Patched the `TimerTimesheetGridDataPoint`, the `TimerTimesheetGridModel` and the `TimesheetTimerRendererHook` classes so that they can contain all the leaderboard data.

sale_timesheet_enterprise_holidays
---------
New module, its purpose is to create a bridge between the sale_timesheet_enterprise and project_timesheet_holidays modules to edit the SQL request in res.company so that it excludes timeoff entries.

task-3436872

This commit adds a brand new system to Knowledge, which is the ability to
add comments to a specific article.

In order to do that, we are using the `mail.thread` mixin with a brand new
model `knowledge.article.thread` which is used to keep every comment as its
own thread.
This model keeps track of its state, it can be resolved and unresolved.
A resolved thread is a thread that is not directly visible in the editor and
is considered as closed: no message should be sent on this thread.
If a thread has been resolved for longer than 1 month, it is removed from the
DB in order to not clog it with stale threads.

In order for user the user to create and handle threads we created 3 Component:
 * `KnowledgeCommentsThread`
 * `KnowledgeCommentsHandler`
 * `KnowledgeArticleCommentsPanel`

`KnowledgeCommentsThread` represents a singular comment thread inside the article
and is used by both the Panel and the Handler.
Each Comment uses a Thread and a Composer that interacts using a thread object.
You can send new comments, react to messages, reply to a specific one or edit
one of your own.
When using a smaller UI the box is replaced by the face of the last person who
commented in the thread. When clicking on it you open a popover that contains
the same elements as the box.

`KnowledgeCommentsHandler` is the link between the editor , the panel, the DB
and the comment system. It handles the creation and destruction of comments,
the changing of state for each comment. It only displays unresolved threads
but keeps track of all the comments.

`KnowledgeArticleCommentsPanel` is a panel similar to the ChatterPanel or the
PropertiesPanel that displays the comments following 3 modes: all, unresolved
and resolved.
You can interact inside the panel like you would with the handler, you can
answer comments, resolve them, etc. but you can also see unresolved comments
and reopen them to relaunch a discussion on a specific part of the article.

COM PR: odoo/odoo#127380
task-3317056

This commit adds modules to allow configuration of an up-front payment for
appointments as well as the payment flow on the front-end. When eCommerce
is not installed, it uses account_payment tools to manage payment. Otherwise,
it is fully managed by classical eCommerce Flow.

*** APPOINTMENT_ACCOUNT_PAYMENT ***

You can now configure a product on appointment_types, of type 'booking_fees'.
This will be the product to buy when booking the appointment. This is a
single 'booking fee' (not per capita atm).

The calendar event linked to the booking should NOT be created until it is paid.
We want to avoid synchronizing calendar events that are not really settled in
terms of payment. Therefore, two new models are created to carry all necessary
booking data. We try to avoid new fields on the calendar.event and to keep new
stored fields introduced in the feature on those new models.

- CALENDAR.BOOKING: counterpart to calendar event, carrying all information linked
to an appointment booking process.
- CALENDAR.BOOKING.LINE: counterpart to appointment.booking.line, this is used
only to store resource booking information (for instance, booking 3 tables adding
up to a certain capacity...)

(Those are technical models and should not be manually updated in most cases)
Availabilities will NOT be modified according to these models, as their existence
should be equivalent to a 'pending' booking, as long as no calendar_event_id is
linked to them. A not paid booking does not reserve any space.

FLOW:
    1) On Appointment Form Submission: we create a calendar.booking and link it
to the booking. An invoice should only be linked to one booking, in this flow.
    2) On invoice payment => create calendar.event from booking values

When do we trigger a 'paid' invoice? On _invoice_paid_hook: this hook is called
on both backend account.payment registration and successful transaction as well
from the payment flow.

    And what about collisions?

If we cannot create an event because the user / resource are not available or
configured correctly anymore, we do not create the event, and log a link to
the form view of failed bookings on the invoice. Manual action will be needed.

A check method _filter_unavailable_bookings is callable on a recordset of
bookings and will try to fit the most bookings according to user / resource
availability. It returns the other ones. This method should be used whenever
an availability check is necessary on bookings. (*)

    How does the front-end payment flow work?

We override payment_pay rendering values to add custom routes and design. We add
a simplified custom payment screen as well. We specify custom cancel and landing
routes. The rest is handled by account_payment and payment tools to pay an
invoice with an access_token, using invoice routes.

On cancelling, the user will have to take another appointment and create another
booking (on a new invoice) The invoice posting is handled by providers and
transaction flow (see existing account_payment controllers)

The landing route is still the page of calendar.event when successfully paid, and
a similar page for the booking otherwise. A new template is added to do so.

    When are bookings removed?

They are collected and removed by the garbage collector, if its stop datetime
was at least 2 months ago, or if created 6 at least months ago. Payments should
be done in that time window.

*** WEBSITE_APPOINTMENT_ACCOUNT_PAYMENT ***

Just a small bridge module to publish data, and payment chevron and update ui
to fit what exists already in website_appointment

*** WEBSITE_APPOINTMENT_SALE ***

When eCommerce is installed, its flow takes over completely. Now, when creating
the booking, we link it to a sale order line. This means someone can book
different slots or appointments in the same cart. We use the request session
if available as we want the description tz and dts to match the one picked
by the user, if any. The lang is the order partner's as per usual sale flow.

When do we trigger a 'paid' SO? We consider that we can do so as soon as
the Sale order is confirmed. This is a bottleneck that is sufficient for
both the case of successful front-end transaction and backend actions.

FLOW:
    1) On appointment form submission, adds a line to cart linked to new booking.
    2) On SO confirm: create calendar.event from booking values

    And what about collisions?

When trying to pay the cart, a check is done to make sure booked slots are
still available (*). Quantity is always set to 1 as fee is unique per booking.
We also log links to failed bookings on SO.

    Confirmation Page

We add a card on SO confirmation page for events and bookings, with appropriate
status, date and apt intro msg, as well as a link to the calendar.event/booking
page depending on whether the SO was confirmed through the transaction and
calendar event was successfully created. For instance if SO had two lines (-> two
bookings), one failed due to collision, one succeeded, then we have one card of
a calendar event, and one of calendar booking (mostly the same)

OTHER CHANGES

- phone is now used in place of mobile in appointment booking flow.
- controllers of appointment (submission...) are restructured for easy overrides.
- constraint added to have either calendar event or booking on answer inputs.

Task-3079302
UPG PR: odoo/upgrade#5289