Purpose
- clean access rights;
- solve some access and security issues;
Access specifications
- an user
- can see all leaves;
- cannot see name field of leaves belonging to other user as it may contain
private information that we don't want to share to other people than
HR people;
- can modify only its own not validated leaves (except writing on state to
avoid bypassing validation);
- can discuss on its leave requests;
- an Officer
- can see all leaves;
- can validate "HR" single validation leaves from people if
- he is the employee manager;
- he is the department manager;
- he is member of the same department;
- target employee has no manager and no department manager;
- can validate "Manager" single validation leaves from people if
- he is the employee manager;
- he is the department manager;
- target employee has no manager and no department manager;
- can first validate "Both" double validation leaves from people like "HR"
single validation, moving the leaves to validate1 state;
- cannot validate its own leaves;
- a Manager
- can do everything he wants
In top of that, multi company rule are correctly added.
In reporting model using in "summary" name field should also be stripped
if you are not an HR officer and if it is not your own request.
Concerning allocation requests: implement same rules except constraint on
name field as it is less private and therefore can be seen.
This commit is linked to task ID 1876795 and PR #26656.
This commit was not correct and was a quick fix to avoid blocking daily use
of odoo saas-11.3. Next commit will fix access rights and enforce their
definition through more detailed tests.
This reverts commit ae34db3221.
This commit is linked to task ID 1876795 and PR #26656 .
Before this, CRUD leaves was limited to department
After this, we go back to what was in 11.2: CRUD for the whole company, and children of it
OPW 1878869
closes#26516
We need to have a clear distinction between holidays managers and
holidays officers.
For this a number of improvements have been done in hr_holidays.
For more informations about the changes see the docstrings of hr.leave
and hr.leave.allocation.
Task #34222Closes#19270
This commit improves leave request and allocation management through a
better integration of activities and addition of automated activities.
Several things are done in this commit :
* leave and allocation models do not inherit from mail.activity.mixin.
This commit adds the inherit so that HR users and managers can now
schedule and manage activities on leave and allocation requests. This
will help them in their daily job;
* automatic activities generation is added for leave and allocation.
Activities are generated for approval and second approval. They are also
automatically set as done when validating or unlinked when refusing or
resetting to avoid bloating users with unnecessary activities;
* a menu to configure activity types is added. Indeed HR managers should be
able to see and configure activity types related to their job;
* filters are added to be able to use the systray and to filter the kanban
view based on activities
Having automated activities allow to replace some messages and tracking
that were implemented to warn people of leave and allocation to approve
or validate. This commit therefore
* simplifies the tracking as only approved or refused state now trigger
a subtype;
* removes to approve and to validate subtypes on leave and allocation
model as well as their parent subtypes on the department. This allows
to simplify chatter a lot in hr_holidays app;
Purpose
=======
Have a clear distinction between leave and allocation requests instead of
using the same model to mix 2 different concepts.
Splitting the model will allow different business code to be run on each
model as allocations and leaves are not exactly the same thing; this
will add some code but simplify future improvements
Specification
=============
1/ Completely separate the models
Model hr.holidays has been split into leave.request and
leave.allocation.
2/ Make reporting working again by using an SQL view aggregating data
from leaves and allocations
A new report has been added in order to aggregate
datas from both allocations and requests. The views have been modified
accordingly.
If a leave request is refused by the manager, the button reset to draft is displayed, but the employee cannot use it because he doesn't have the write access rights on his own leave requests
In 'refuse' state, all the form is readonly, but the employee should be have to reset his own leave to draft to modify it and re-submit it.
PURPOSE
=======
For each and every Hr application there should be one user category (One app = one category).
SPECIFICATION
=============
HR remains as it is : Employee, Officer, Manager
Each Application should have 2 access rights: User and Manager. Example for Recruitment:
- The user has access to the recruitment process
- The manager has access to the job position configuration
Each Application should grant the employee user access right (Namely the 'HR Officer')
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
- added encoding to xml files
- replace search_read() with search() for _search_absent_employee()
- fixed setting first date of current month as default value for wizards
- reduce calls to <dict>.get()
In order to avoid all users being able to see leaves from everyone
the record rule is updated so that users see only their own leaves.
Code computing leave on employee record now uses super user to compute
it to ensure the current status of an employee is visible to other
employees.
Dashboard menus is now restricted to group hr_manager.
- New calendar dashboard with the leaves of every employee
- New "Leaves to Approve" menu with to-approve department leaves
- Renamed and reorder menus
Odoo Task 12913
Closes#7292
Nor modify once approved
It wasn't possible for employees to approve their holidays themself, thanks to the GUI, but this was possible through xmlrpc calls, or when altering the html directly in the browser.
Besides, this was also possible to edit the holiday through the same trick once the holiday validated
- added a workflow transition from refuse to draft, to allow resetting
a refused request
- resetting is now based on a can_reset field, taht is based on whether
it is my own request or I am an hr manager
- added an access right on crm_meeting that was preventing hr officers
to validate some requests
- improved form view to show reset to draft button accordingly
- added tests that helped trigerred the various bugs and improvements
bzr revid: tde@openerp.com-20130809144752-o21pjbc56o0t8fym
Christophe Simonis