New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IMP] Add employee profile #30502

Merged
merged 6 commits into from Feb 14, 2019

Conversation

Projects
None yet
8 participants
@Musvol
Copy link
Contributor

Musvol commented Jan 24, 2019

[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

@robodoo robodoo added the seen 🙂 label Jan 24, 2019

@C3POdoo C3POdoo added the RD label Jan 24, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Jan 24, 2019

@robodoo robodoo added the CI 🤖 label Jan 24, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Jan 25, 2019

@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 25, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Jan 25, 2019

@robodoo robodoo removed the CI 🤖 label Jan 25, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Jan 25, 2019

@robodoo robodoo added the CI 🤖 label Jan 25, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Jan 29, 2019

@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Jan 29, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Jan 29, 2019

@robodoo robodoo removed the CI 🤖 label Jan 29, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Jan 29, 2019

@robodoo robodoo added the CI 🤖 label Jan 29, 2019

Show resolved Hide resolved addons/hr/data/hr_data.xml Outdated
Show resolved Hide resolved addons/hr/models/res_config_settings.py Outdated

@api.constrains('pin')
def _verify_pin(self):
for employee in self:
if employee.pin and not employee.pin.isdigit():
raise ValidationError(_("The PIN must be a sequence of digits."))

@api.onchange('parent_id')
def _onchange_parent_id(self):
manager = self.parent_id

This comment has been minimized.

@fmdl

fmdl Feb 1, 2019

Contributor

add
self.ensure_one()

This comment has been minimized.

@tivisse

tivisse Feb 11, 2019

Contributor

Useless in an onchange FYI

addons/hr/models/hr.py Outdated
_sql_constraints = [('barcode_uniq', 'unique (barcode)', "The Badge ID must be unique, this one is already assigned to another employee.")]
_sql_constraints = [
('barcode_uniq', 'unique (barcode)', "The Badge ID must be unique, this one is already assigned to another employee."),
('user_uniq', 'unique (user_id)', "A user cannot be linked to multiple employees.")

This comment has been minimized.

@fmdl

fmdl Feb 1, 2019

Contributor

maybe add the company_id field.
an user for two company, can be an employee in each company. No ?

('user_uniq', 'unique ((company_id,user_id))', "A user cannot be linked to multiple employees.")

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Feb 5, 2019

@robodoo robodoo removed the CI 🤖 label Feb 5, 2019

@RomainLibert
Copy link
Contributor

RomainLibert left a comment

Technical review for this PR
Functional review will follow

addons/hr/models/res_users.py Outdated
"""
init_res = super(User, self).__init__(pool, cr)
# duplicate list to avoid modifying the original reference
type(self).SELF_WRITEABLE_FIELDS = list(self.SELF_WRITEABLE_FIELDS)

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

That's somewhat strange to do this in init
It should probably be done either directly in the body of the class or in the new method

nb:
It works like this but it is strange to have :

User.SELF_READABLE_FIELDS != User().SELF_READABLE_FIELDS

moreover doing

User()
User()
User()
print(User.SELF_READABLE_FIELDS)

will print a very long list of fields

This comment has been minimized.

@Musvol

Musvol Feb 6, 2019

Author Contributor

How would you do it in the body of the class ?
What do you thing of the override below ?

def __new__(cls, *args, **kwargs):
        """ Override of __new__ to add access rights.
            Access rights are disabled by default, but allowed
            on some specific fields defined in self.SELF_{READ/WRITE}ABLE_FIELDS.
        """
        cls_instance = super(User, cls).__new__(cls, *args, **kwargs)
        # duplicate list to avoid modifying the original reference
        cls_instance.SELF_READABLE_FIELDS = cls_instance.hr_expense_fields + cls_instance.SELF_READABLE_FIELDS
        return cls_instance

*args and **kwargs are not necessary, I'm not sure it's a good idea to have them or not

addons/hr/models/res_users.py Outdated
# If the company policy doesn't allow self edition:
# Check normal access rights for hr.employee fields
hr_related_fields = { k for k, f in self._fields.items() if f.related_field and f.related_field.model_name == 'hr.employee' }
if not self.env['ir.config_parameter'].sudo().get_param('hr.hr_employee_self_edit') and vals.keys() & hr_related_fields:

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

store vals.keys() & hr_related_fields in a boolean in order to compute it only once

$chat_button.hide();
}
else {
$chat_button.off('click').on('click', self._onOpenChat.bind(self));

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

Not sure, but I think the event handling should be in the controller

This comment has been minimized.

@Musvol

Musvol Feb 8, 2019

Author Contributor

Actually this event handling function only triggers up a custom event. And it's the controller that really handles it. Not sure if it's the right way (it adds an intermediary handle function), but that way the controller doesn't know about the DOM element which triggered it

addons/hr/models/res_users.py Outdated
self.check_field_access_rights('write', list(vals))
except AccessError:
# Raise meaningful error message
raise AccessError(_("You are only allowed to update your preferences. Please contact a HR officer to update other informations."))

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

This could probably be rewritten to look like this

hr_field = vals.keys() & hr_related_fields
can_edit_self = self.env['ir.config.parameter'].sudo().get_param('hr.hr_employee_self_edit')
try:
    if hr_field and not can_edit_self:
       raise AccessError()
    super(User, self).write(vals)
    self._notify_hr_employee(vals)
except AccessError as e:
    if hr_field:
        raise AccessError(_("You are only ..."))
    raise e

This comment has been minimized.

@Musvol

Musvol Feb 5, 2019

Author Contributor

What about:

hr_field = vals.keys() & hr_related_fields 
can_edit_self = self.env['ir.config_parameter'].sudo().get_param('hr.hr_employee_self_edit') \
 or self.env.user.has_group('hr.group_hr_user')

if hr_related_fields and not can_edit_self :
    raise AccessError(_("You are only..."))
super(User, self).write(vals)

Which avoid the try/except and re-raising the exception.
And can_edit_self is True for a member of group_hr_user to edit his employee through its profile (otherwise he would have an access error through his profile but not through the employee form)

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

Yes now that we don't need to call _notify_hr_employee anymore this looks way better

addons/hr/models/res_users.py Outdated
# We make the front-end aware of those fields by sending all field definitions.
return super(User, self.sudo()).fields_view_get(view_id=view_id, view_type=view_type, toolbar=toolbar, submenu=submenu)

def _notify_hr_user(self, vals):

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

Maybe call this _notify_hr_employee

Show resolved Hide resolved addons/hr_maintenance/models/res_users.py
@@ -14,6 +14,7 @@
(N+1, N+2, direct subordinates)
""",
'depends': ['hr'],
'auto_install': True,

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

Why set this module in auto_install?

This comment has been minimized.

@Musvol

Musvol Feb 5, 2019

Author Contributor

apr request

addons/hr_org_chart/static/src/js/hr_org_chart.js Outdated
@@ -75,7 +75,8 @@ var FieldOrgChart = AbstractField.extend({
}));
}
else if (!this.employee) {
this.employee = this.recordData.id
// the widget is either dispayed in the context of a hr.employee form or a res.users form
this.employee = this.recordData.employee_ids ? this.recordData.employee_ids.res_ids[0] : this.recordData.id;

This comment has been minimized.

@RomainLibert

RomainLibert Feb 5, 2019

Contributor

Be careful with this code, in js an empty list is not falsy
eg :

var a = [];
if (a) {
    console.log('Hello');
}

Will output Hello

This comment has been minimized.

@tivisse

tivisse Feb 12, 2019

Contributor

Did you check that comment ?

This comment has been minimized.

@Musvol

Musvol Feb 12, 2019

Author Contributor

this.recordData.employee_ids is an object and is undefined if the org chart is displayed from a hr.employee form view. It should be good as it is.
I will change it to this.recordData.employee_ids !== undefined ? ... to make it explicit.

Show resolved Hide resolved addons/hr_pin/models/res_users.py Outdated
Show resolved Hide resolved addons/hr_skills/models/hr_skills.py Outdated

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch 5 times, most recently Feb 6, 2019

@@ -34,37 +34,6 @@
<field name="perm_write" eval="False"/>
</record>

<!-- Security restriction for private addresses -->

This comment has been minimized.

@Musvol

Musvol Feb 8, 2019

Author Contributor

These rules were defined twice

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch Feb 8, 2019

@tivisse

This comment has been minimized.

Copy link
Contributor

tivisse commented Feb 13, 2019

@robodoo r+ merge

@robodoo robodoo added the r+ 👌 label Feb 13, 2019

@robodoo

This comment has been minimized.

Copy link
Contributor

robodoo commented Feb 13, 2019

Merge method set to merge directly, using the PR as merge commit message

@robodoo robodoo added the CI 🤖 label Feb 13, 2019

@VincentSchippefilt

This comment has been minimized.

Copy link
Contributor

VincentSchippefilt commented Feb 13, 2019

robodoo r-

@VincentSchippefilt

This comment has been minimized.

Copy link
Contributor

VincentSchippefilt commented Feb 13, 2019

because there is a bunch of javascript that depends on the list_renderer, and it is ment to change, you cannot merge this PR without JS tests.

@robodoo robodoo removed the r+ 👌 label Feb 13, 2019

* Don't render any footer
*/
_renderFooter: function () {
return;

This comment has been minimized.

@VincentSchippefilt

VincentSchippefilt Feb 13, 2019

Contributor

return $('<div>')

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch from 6e4cce7 to 1ea5e4a Feb 14, 2019

@robodoo robodoo removed the CI 🤖 label Feb 14, 2019

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch from 1ea5e4a to a365f5b Feb 14, 2019

@Musvol

This comment has been minimized.

Copy link
Contributor Author

Musvol commented Feb 14, 2019

Hello @VincentSchippefilt
I've added some js tests for skill widgets.
Can you take a look, comment or r+ if you are ok?
Thanks

@robodoo robodoo added the CI 🤖 label Feb 14, 2019

Musvol added some commits Feb 12, 2019

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

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.

hr_attendance
=============

This commit integrate attendance in the new employee profile.
It also 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 15 minutes.
-> The status is accurate on the report view (status is still updated
   when loading the view)
-> The status in accurate at 15 minutes on the kanban view

[ADD] hr_attendance_presence
============================

Bridge module between hr_attendance and hr_presence.

This commit 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
[FIX] hr_holidays: reload dashboard on new allocation
When a new allocation is requested from the leave dashboard,
the page is not reloaded. Therefore the displayed data is not
up to date with the new allocation count.

This commit makes the page reload after each new allocation.
[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 informations are also useful to statistics.

Specification
=============

New models
----------

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

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

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

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

5/ `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%)*

6/ `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.

@Musvol Musvol force-pushed the odoo-dev:master-employee-profile-lul branch from a365f5b to bad9190 Feb 14, 2019

@robodoo robodoo removed the CI 🤖 label Feb 14, 2019

@VincentSchippefilt

This comment has been minimized.

Copy link
Contributor

VincentSchippefilt commented Feb 14, 2019

robodoo r+

@robodoo

This comment has been minimized.

Copy link
Contributor

robodoo commented Feb 14, 2019

Linked pull request(s) odoo/enterprise#3497 not ready. Linked PRs are not staged until all of them are ready.

robodoo added a commit that referenced this pull request Feb 14, 2019

[IMP] Add employee profile
[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

closes #30502
@robodoo

This comment has been minimized.

Copy link
Contributor

robodoo commented Feb 14, 2019

Merged, thanks!

@robodoo robodoo closed this Feb 14, 2019

@robodoo robodoo merged commit bad9190 into odoo:master Feb 14, 2019

2 checks passed

ci/runbot runbot build 449860-master-employee-profile-lul-bad919 (runtime 2633s)
Details
legal/cla Lucas Lefèvre Odoo CLA signature check
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment