We need to support the accrual allocation for leaves.
This is a special type of allocations that adds some leaves to the
allocation every X amount of time worked.
This kind of allocations is especially used in the USA, but can also be
used in other contexts (eg: In Belgium we could allocate 20 days per
year for the legal leaves)
These allocations have support for :
* A max balance limit
* Going in negative (if set on the leave_type and the manager
approves the leaves)
* Removing the unpaid leaves from the quantity of days worked
* Setting an end date after which it does not allocate anymore leaves
Task #46114Closes#22292
We would like to be able to take leaves using different units, currently
we only support taking leaves by hours because we use datetimes.
We need to support three units:
* days
* half days
* hours
These units will be defined on the leave type.
Task #40995Closes#21760
Refactor resource calendar and resource mixin:
- add a required timezone field on models 'resource.calendar' and 'resource.resource';
- resource calendar attendances are now computed in the timezone of the resource
or the calendar;
- improve API of 'resource.calendar' and 'resource.mixin';
- avoid other modules from using the implementation methods of 'resource.calendar';
- refactor implementation of 'resource.calendar' to make it more efficient.
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
It was possible to edit a leave request in order to use a leave type
which had no more days left. This was due to a missing field in the
constrains call.
Closes#24320
As we have two parallel tasks changing the rights for the approval of
leaves, we have to make sure that it stays coherent.
Basically by default an hr_holiday manager can approve anything and the
hr_holiday officer can only approve the leaves of his department and
cannot approve his own leaves.
But you can override this behaviour by setting the Validation By to
"Manager" which will force the leave to be approved by an hr_holiday
manager.
The label and the help message for override limit were confusing, it is
now changed for a less confusing label and help message.
Another confusing thing is that when having a leave type able to
override the limit it should not be visible in the allocations hence it
should not be possible to set the visibility option.
Commit 565ab7a2e4 added a bypass to message subscription because some auto
subscription is done without the right to edit the record. However there
are two issues with this commit
* message_subscribe API changed and code tried to pass now removed parameters;
* sudo-ing without checking any access rights before is a security issue;
This commit fixes the call and add an access right on read. As few people
(mostly HR officers and managers) can read a leave request it solves the
issue of auto subscription while a better solution is found.
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 refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
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;
When changing the employee to None in an allocation,
this onchange raised an error because it attempted
to set an employee browser record (empty but still)
in a department many2one.
- Create a new leave allocation
- Try to change the field Mode (holiday_type) from "By Employee" to "By Employee Tag"
Fixes#23345
opw-1820069
This commit renames some internal mail.thread methods linked to the
notification process. This is the next commit of a series aiming at
improving code readability and method finding through prefixes. See
notably cae1c3977f, cdfe479e2e and fc1348dd3d.
This commit does not change any functional feature. It does only
rename notification-related methods, using the _notify prefix to
ensure they are private and to mark they are part of the notification
process.
We would like to have an overview of project forecast that include
leaves, for this we need to implement several kind of 'leaves' directly
in resource module.
These kind of 'leaves' can be defined via the hr.leave.type model (only
visible in base.group_no_one (choices currently are 'leave' and 'other')
* Add field time_type on resource.calendar.leaves
* Add a domain restriction that allows for filtering on this field
* Add tests
- In SaaS-16 we have added a related on the employee's department.
This causes access rights issues when changing the employee's department.
We do not want to rewrite all the old records, only the new ones should use the new employee's department.
In order to help limit leaves recording errors. We need to add some
configuration on leave type object. For example we need to avoid people
taking legal leaves 2016 on 2017.
* Add validity dates : start and end dates on the leave type. An empty
end date means forever
* Double validation : change the checkbox into a radio button with now
three choices :
- Human Resource Responsible
- Manager
- Double Validation
* Add a sequence field, using handle widget
* Add a field, to specify if the employee can select the leave type in
his allocations, requests or in both of them
- In SaaS-16 we have added a related on the employee's manager as the manager of the leave.
This cause access rights issues when changing the employee's manager.
We do not want to rewrite all the old records, only the new ones should use the new manager.
Notification emails contain a link to the record. Before 6187ffa258
it was necessary to choose whether to display leave or allocation as
button label. It is not necessary anymore since each concept has its own
odoo model. Standard behavior is now sufficient as it displays the model
description, now leave or allocation. The unnecessary code is therefore
removed.
Using a working calendar, you might want to know
how much hour correspond a work day. This depends
of you working calendar. This might be usefull to
compute leave duration (half a day is not 8 hours,
but 4).
The hours_per_day field is not computed as the
average of working hour of all work day of calendar
to allow customization. By default, it is 8, as
the default attendances are the one from the
40h/week calendar.
A constant is also available to handle case where
resource calendar is not available.
Purpose
=======
Follow the coding guidelines (https://www.odoo.com/documentation/11.0/reference/guidelines.html)
Specification
=============
* each model has now its own .py file
* view files have better names
* reordered the methods for readability
* reimplemented email subtypes
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.
Priyanka Kakadiya