PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
Next to 883c96b781 and recent ribbon widget update some form views
have to be updated. It is best displayed following those rules
* after oe_button_box in order to fix overlapping;
* before image to overlap it cleanly;
LINKS
Task ID : 2032621
PR : #34662
Task
hr:
-rename btn 'generate badge ID' to 'generate'
-When the badge ID is set, replace the button Generate by "Print Badge"
hr_attendance:
-Rename menu 'Manage Attendances' to "Manager"
-Add a column "Work Hours" to attendee tree view
-Add a <br> after "Welcome to"
-add class text-muted on "or"
-remove class "text-muted" on "scan your badge
-Rename the primary btn into "Identify Manually"
Task-2040884
Closes: #35473
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
If we use a kanban view to select a record we want to hide those elements:
dropdown boxes, buttons, anchors, some widgets, kanban color.
When it was too much change and used the new attribute
"kanban_view_ref" to explicitly define which view to open in selection_mode.
When also had to create previously unexisting kanban for
fleet.vehicle.model to show name and brand.
Task ID : 1924779
All activity filters are now invisible in the corresponding search views.
These filters were only used by activity redirection (when clicking on
the activity item in the systray) so we hide them to reduce the noise
for the user.
"My Activity" filter has also been removed, its corresponding domain is
now directly set in the action where it was used.
Task 2036392
The following models are already using big images, or they might need big images
in the future:
- partner
- hr employee
- shop category
- lunch product
- gamification badge and karma rank
PR: #34925
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
When a user change his langage in employee profile, he doesn't see
the result before reloading manually the page.
With this commit, when a user change his language, the page is
reloaded on saving. And remove Create button on My Profile
closesodoo/odoo#34906
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1/ web: adapt formatDate to handle NaN values
DashboardRenderer might return NaN for `Date` or `DateTime` fields if
their original value is null or incorrect.
2/ hr: add job_title in demo data
3/ hr_recruitment: link employee in the chatter for new recruits
4/ hr: remove employee documents in the model
5/ hr_attendance: improve resiliency of relative_time
6/ hr: display manager on res_users
7/ hr: change Address Book to Employee Directory
TaskID: 2009111
closesodoo/odoo#34180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
There are currently multiple ways to determine if an employee is presence
or absent:
- login state (user status on chat)
- checkin/checkout from the Attendance app
- leave
- hr_presence (email, ip)
Those states are displayed in several different places and can be inconsitent.
e.g. Logged in -> green in the chat
Not checked in -> red on the employee kanban view.
The multiple ways to determine employee presence described above
should be aggregated together to have a better consistency.
Specification
=============
There are 3 presence states (previously defined in module `hr_presence`),
namely `present`, `absent`, `to_define`. They are now defined as soon as
`hr` module is installed.
The state computation can have several behaviors according to which apps
are installed:
1. `hr` is installed
Check employee presence based on login by default (only for employees with
a user).
Kanban state (private and public): should be green when logged in, red when logged out and
orange when the user is away.
Private employee form: Display a stat button "Connected" on the form view
when the user is logged in or "Last Activity xx/xx/xxx" otherwise.
2. `hr_attendance` is installed:
when the user is logged out, the state
is determined from the checked in/out state. But when the user is logged in,
consider the user as present (even if he checked out).
Kanban state: green for checked in, red for checked out
Private form view: attendance stat button.
3. `hr_holidays` is installed:
Has the highest priority if the employee is on leave.
Kanban state: red if employee is on leave.
Private form view: stat button "Absent Until xx/xx/xxxx" if employee
is on leave.
4. `hr_presence` is installed:
Two additionnal presence checking option: emails sent and IP address connected.
Once a user sent an email or the IP address was connected, he is considered
present for the entire day.
There should be at most one stat button on the employee form view, with the
relevent information.
Task id: 2024482
closesodoo/odoo#34933
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Some formviews are useless since there are so few relevant fields https://nimb.ws/1EdMV7
For instance, to create a new lost reason the user is forced to:
1. Hit create
2. Type in the name of the record
3. Hit save
4. Go back to the treeview
While he could simply type them away in an editable treeview.
The goal of this task is to allow for creation/edition of records in such models
directly from the treeview.
Specification
=============
Modify tree views from a given list of models for which the
treeview has to be made editable bottom.
If not specified otherwise, the content treeview should stay the same.
If a field is readonly/required/etc. in the formview, it should be in the
editable treeview as well.
Relabeling has to be done of the field itself, not in the view.
TaskID: 2026126
closesodoo/odoo#34577
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
=============
Remove the 'active' stat buttons in all views
* attendance, contract, fleet, holidays, maintenance, presence,
timesheet.
For the model 'hr.employee', replace the actions menu 'Archive/Restore'
by the stat button. That's why adapted changes regarding xpath.
Also rename the actions menu 'Time Off' by 'Time off'.
Linked to task 1984526
Related to PR #33720
- On the HR module, the field `parent_id` is added on `res.users`.
The issue here, is that `res.users` inherits the fields from
`res.partner` where `parent_id` is already defined.
This causes issues when trying to read the parent `res.partner`.
Issue found by @rrahir
closesodoo/odoo#34059
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
The field job_id is displayed in the tree view but it was not available in the form view
like in 12.0. So it was not possible to change it.
opw:2006084
closesodoo/odoo#33933
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purpose
=======
1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)
Specification
=============
Introduce 2 new models:
- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).
The model hr.employee is not readable anymore for an employee.
There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.
Purpose
=======
As the employee picture on a form view is often too small,
it should be possible to zoom on it like for products in eCommerce.
Specification
=============
Added new bool options on FieldBinaryImage: `zoom` and `background`.
`zoom` will call zoomOdoo.js and display a popup with the zoomed out
image.
`background` is used to either display the image as a div element with
a background-url (to be used e.g. in a kanban view) or as a standard
img element.
closesodoo/odoo#33839
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Now that the multi company mode is much more easier to
activate, it is needed to display this information on the
tree views, to help people to know on which company is
set some records in list view.
task-1997637
Closes: #3397closesodoo/odoo#33976
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In employee searchpanel (left) view, In 'tag' selection, their could be a lot
of records so it seems useless. That's why it has been removed by this commit.
task-1974632
closes: #33701
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- The added field `phone` on `res.users` shadow the field `phone`
inherited by `res.partner`.
The issue is that the field `phone` on `hr.employee` can be read only
by the employee or the HR team.
A lot of views tries to display the field `phone` expecting the one
declared in `res.partner` which should be readable by everyone.
But the one declared in `res.users` shadows it.
closesodoo/odoo#33569
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
The activity view has been added on multiple models (invoice, fleet
contract, vehicles, leads, employee, contract, expense, expense sheet,
leave, leave allocation, applicant, partner, product, task, purchase
order, sale order) to ease the creation and the management of
related actvities.
Task 1894990
Like other models with a chatter (sales, stock, ...) it is possible to
schedule activities on employees. Scheduling an activity add the
activity to the activity menu (top-right *clock* button) where activities
are classified as *late*, *today* or *future* and grouped by
application. Clicking any of the three class on an employee activity
shows all activities regardless of their class.
opw-1957013
closesodoo/odoo#32657
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In the user preference, change the timezone of the user to blank (False value)
Save
Before this commit, a cryptic error was raised because the field tz in
resource.resource is required
Note that when writing on res.user, we write some fields (including tz)
on hr.employee, which is a resource.mixin, and therefore uses resource.resource
After this commit, we make the field required in the view
OPW 1934462
closesodoo/odoo#31312
Compute notice duration and if the notice duration is not respected,
a report about termination fees is generated.
At the end of the notice duration, we can generate a certificate
about time off not taken and an other about time off for the next
year.
TaskID: 1914556
- hr.job receives the favorite functionnality.
- Now, a newly created hr.job is favorite by default.
- hr.job receives a new field new_application_count that computes
the number of applications which are new in the flow for that job
(1st step of the recruitment flow).
- hr.job kanban boxes now display the field described just above.
- hr.job kanban boxes are now clickable and thus open related applications in a kanban view.
- Views are modified according to the images given in the related task (see Task ID below).
These changes are details such as modifying strings that are displayed or their position
in the view, or again icons that are displayed.
-> Note : Check related task to see decisions that have been made concerning these images.
- Search on Email on hr.applicant has been separated so that it is clearer.
- Rename old view crm_case_form_view_job into hr_applicant_view_form
Task ID : 1896305
Purpose
=======
If the activities are available on a model (i.e. inherits mail.activity.mixin),
add a progress bar based on the activities if nothing is defined yet.
closesodoo/odoo#24777
[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
closesodoo/odoo#30502
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.
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
Lucas Lefèvre