Purpose of this merge is to provide a completely new and improved user profile
page linked to gamification, slides and forum. Those frontend applications
now heavily rely on website profile and add their own custom content like
channel or forum participation or challenges results. This merge is linked
to the currently under development eLearning feature [1][2].

This merge contains notably

 * review website profile page centralized in a new module : website_profile;
 * move everything that was linked to the profile from website_forum in
   website_profile;
 * properly add forum informations in website_forum through inheritance;
 * add channel / course informations in website_slides through inheritance;

A new bridge module is added that is website_slide_forum. It makes a link
between those two applications. Publishers can create a forum linked to a
course allowing participants to communicate and ask questions related to a
course.

Profile page is contextualized. When coming from a channel informations about
this channel is displayed. Linked forum information is added. When coming from
a specific forum only information related to this forum is displayed.
Otherwise a profile page with aggregated information is displayed.

Some other improvements are done: ranks, karma, badges from gamification are
included in forum and eLearning, 'new badge notifications' mechanism is removed
as email are send, and various other improvements. See sub commits for more
details.

Merge linked to task ID 1922159.

[1] see task ID 1902304 (main eLearning task) PR #29876;
[2] see task ID 1936153 (new homepage for slides) PR #30770;

[IMP] hr_*: introduce the employee profile
================================

## General Purpose

We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the `hr` module is installed and the current user is linked to an employee. The Profile will show the employee of the current company.

A user should be able to see and edit his own profile.

*Problem*:
Many fields on hr.employee are protected by `groups="hr.group_hr_user"`.
Therefore, a regular user cannot see or edit those fields.

This protection must be bypassed to allow read/write access to the regular user's own data.
A similar mechanism already exists for `res.users` (for Preferences)

The better (least worst) solution found is to reuse this mechanism by adding related fields on `res.users`.

Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
  It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
  are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
  through the Preferences menu.
  E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
  must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to `SELF_[READABLE | WRITABLE]_FIELDS`

Note:
When the front-end loads the views it gets the list of available fields for the user (according to its access rights). Later, when the front-end wants to populate the view with data, it only asks to read those available fields. However, in this case, we want the user to be able to read/write its own data, even if they are protected by groups (groups are kept on the related fields on res.users). The front-end need to be made  aware of those fields by sending all field definitions.

## Changed modules

### hr_attendance

Adds a stat button to this employee profile showing the number of hours worked last month.

Remove the Boolean computed field `manual_attendance`.
This field is just a shortcut to add/remove the employee's user in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should be done through the normal group management screens.

### hr_presence

Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present), orange (to define) or red (absent).

Currently, the presence status is only computed when accessing the report view. As this commits displays it on the employee kanban, it should be updated more frequently.
The state should not be updated every time the kanban view is loaded since the computation is a bit heavy. Instead: add a cron to update status every hour.
-> The status is accurate on the report view (status is still updated
   when loading the view)
-> The status in accurate at 1 hour on the kanban view

### [ADD] hr_attendance_presence

Bridge module between `hr_attendance` and `hr_presence`.

This PR integrates `hr_presence` module in the employee profile and adds the presence status on the employee kanban view. But `hr_attendance` adds at the same place a similar status icon for checkin/checkout.
This bridge module makes the status from `hr_presence` invisible as `hr_attendance` should be the main presence control mechanism.

Also, this commit adds the ability (through a new setting option) for `hr_presence` to take into account checkin/checkout to determine the presence status.

### l10n_be_hr_payroll
integration with employee profile

[ADD] hr_skills: Introduce a new module for employee resumé and skills
=======================================================

Purpose
-----------

Consultancy companies need resumé and skills of their consultants.
For big projects, they often need to send them to their customers.
These information are also useful to statistics.

Specification
-----------------

### New models


####  `hr.resume.line.type`
Types of resumé lines. e.g. *Experience*, *Education*, *Hobbies*

#### `hr.resume.line`
It is a line in the resumé of an employee.

#### `hr.skill`
Name of a skill. e.g *French*, *Python*, *Piano*

#### `hr.skill.type`
Skills can belongs to a particular type. A skill type has skill levels associated.
e.g. *Languages*, *Dev*, *Music*

#### `hr.skill.level`
Levels available for a particular skill type. Each level has a label
and a progress (between 0 and 100) associated.
e.g. *Intermediary (20%)*, *Advanced (85%)*, *Expert (100%)*

#### `hr.employee.skill`
These are skills which employees have. It links an employee with a particular skill
and level.
e.g. Mitchell has an *Intermediary* level in *Python*

### Access Rights

Only a `hr_user` can create/edit `hr.resume.line.type`, `hr.skill`, `hr.skill.level`, `hr.skill.type`.
If employees are allowed to edit their infos (setting), they can also create/edit `hr.resume.line`,
`hr.employee.skill` for themselves.

### UI

Resumé lines are displayed, grouped by type, in a new 'Resumé' tab in the employee
form. Resumé lines can be reordered (handle widget)

Emloyee skills are displayed in the Resumé tab, grouped by skill type.

[IMP] hr, hr_holidays, hr_expense: Change onchange parent_id behaviour
=========================================================

Purpose
-----------

When the manager (parent_id) of an employee changes, it doesn't always mean that other responsibles (Leave responsible, expense responsible, coach) should also change.

Specification
-----------------

When changing the employee's manager, the leave responsible, the expense responsible and the coach should be changed only if the field was not set or if the responsible is the previous manager. In that case, they should be set to the new manager. Otherwise, it means the field was most probably set manually and it should be left unchanged.

Task 1913089

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

[IMP] hr_appraisal, hr_documents, timesheet_grid: integration to employee profile
==============================================================

This PR is part of the new employee profile

### hr_appraisal

This commit integrate appraisals to the new employee profile.
It adds a button to allow a user to request an appraisal (see below)
Also adds a stat button displaying the date of the next appraisal.
The button redirects to the employee's appraisals.

An employee should be allowed to request an appraisal himself
through his profile.

Additionnal settings are added to control requests.
The maximum and minimum appraisal frequency.
e.g.:
  max = 6 month and
  min = 18 month
  -> An employee cannot request a new appraisal if 6 month
     haven't passed since the last one.
  -> A new appraisal will be created if 18 month (minus 7 days)
     have passed since the last appraisal.

### hr_documents

New bridge module allowing to integrate Documents to the new employee profile.
Add a stat button on the employee profile linking to its documents.

### timesheet_grid

Move timesheet responsible in the Managers section of the employee profile

[IMP] timesheet_grid: Change behaviour of onchange parent_id
=================================================
#### Purpose

Currently, when an employee is assigned to a new manager,
his timesheet responsible is also set to this new manager.
However, assigning a new manager to an employee does not
always mean that the timesheet responsible should also change.

#### Specification

When changing the employee's manager, the timesheet responsible
should be changed only if the field was not set or if the
responsible is the previous manager.
In that case, the timesheet responsible should be set to the
new manager.
Otherwise (timesheet responsible is an other person than the
previous manager), leave the responsible unchanged.

Task 1913089