Currently, it's possible to add supporting documents on the chatter of
the time off. But it's not easy to use and doesn't make really sense.
So we will add the possibility to add it more easily.
So in this commit,
- Added 'Supporting Document' on Time Off type to support the
attachment based on types.
- On new Time Off, if the Time Off type has a support document then allow
uploading the supporting document in form view.
- The File is recorded on the chatter of the Time Off request.
- There will be synchronization between chatter and form attahcments.
PS: added non-stored m2m field to display the attachment view(m2m_binary)
in the form view as o2m does not support it.
TaskID: 2431478
In relativedelta, `day` means day of the month and `days` is for number
of days. Today, the demo data failed because the computed `date_to` was
before the `date_from`.
closesodoo/odoo#68632
X-original-commit: 67cb39aa74ae60dd069bf552ed06c878ec643f9c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Followup to odoo/odoo#65314: turns out there's a bunch of other leave
requests in the file which will eventually fall on a weekend, and will
probably blow up due to the new validation in 14.0:
- hr_holidays_sl_al in March 2021 because April 17th, 2021 is a
saturday
- hr_holidays_cl_mit_2 in June 2021 because June 5th, 2021 is a
saturday
- hr_holidays_sl_vad in September 2021 because September 25th, 2021 is
a saturday
- hr_holidays_sl_kim in April 2021 because May 1st, 2021 is a saturday
- hr_holidays_sl_kim_2 in March 2021 because July 3rd, 2021 is a
saturday
Solution
========
Instead of hard-coding month-days, move to the first monday after the
original date e.g. if we were looking for the 20, now get the monday
after the 22. In relativedelta terms, `weekday=0` is "the next
monday". The date is then formatted inclusive of the month-day rather
than hard-coding one.
One nit is for the end date:"the next wednesday" may come before "the
next monday" if we're on TU or WE. So we need to first jump to the
next MO *then* to the WE after that, which makes the code a bit
longer (and more redundant). As a result the end date is now "the
wednesday after <the start date>" rather than being a literal 2 days
later or whatever.
The PR updates all the 1-day and 2-day intervals, it also updates the
3 days inclusive (those over 3 which include start and end dates
rather than without) including those updated by #65314 for clarity /
coherence of small intervals. Longer intervals are left untouched,
although we may eventually want to update them so `number_of_days`
computations are more reliable.
Redundancy issues
-----------------
There are a bunch of redundancies / verbosities which don't seem
easy or possible to remove:
* While lxml does resolve entities by default it doesn't load
DTDs (let alone validate them), aliasing various datetimes
& deltas as entities is not an option, not to mention for security
reasons we'd rather stop resolving entities entirely than allow
custom ones.
* While it's possible to define nested safe_eval'd `context` on nodes,
the evaluation context for *those* contains neither datetime nor
relativedelta, so storing a bunch of constants in the (environment's)
context and using that in the expression is not an option either.
* Leaving `date_from`/`date_to` off of some records breaks, probably
because some other field necessary to properly compute *them* is
missing.
Other changes
=============
* Removed explicit settings to `number_of_days` and explicit calls to
`_compute_number_of_days`, seems redundant and unnecessary as the
compute works fine as long as we let it.
* While at it, updated the calls to `action_approve`: moved them next
to the corresponding record (instead of being on the other side of
the file) and used direct references to the subject records rather
than complicated searches.
* Also updated two leave allocations to be created validated OOTB
instead of manually calling action_validate as that's what's being
done elsewhere in the file.
Notes
=====
* In relativedelta lingo, "the next X" is inclusive of the current
date e.g. when looking for the next WE, if the date being offset is
already WE there will be no movement, this can be unexpected.
* Normally relativedelta would be used with the MO/TU/WE/... constants
for weekdays, but we're not exposing those to `@eval` so integer
literals it is.
closesodoo/odoo#65430
X-original-commit: 7840b21483c0012174e6028a39b114ce56f06158
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
All fields not provided default to 0, so the the exact values are
`%Y-%m-20 00:00:00` - `%Y-%m-22 00:00:00`.
Because this is only 2 days it can entirely overlap with a week-end
(e.g. 2021-02-20/21), leading to `number_of_days` computed to 0 and
triggering an error at confirmation (`"The following employees are not
supposed to work during that period"`).
Change familly trip as the same issue would occure in May 2021
closesodoo/odoo#65326
X-original-commit: ada1da9a0cea6aaa3f91ee34fd3b273be79e1e3d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose
=======
We want to allow different approvals for allocations and leaves of a same type.
e.g. In case of compensation days, a manager would approve the
allocation request, but would later not approve leave requests.
Specification
=============
Allocation modes
----------------
No change here except renames.
1. No limit (employee doesn't need an allocation to request a leave)
2. Allow employee requests
3. Fixed by Time Off Officer
Allocation approval
-------------------
A radio field to choose the approval mechanism
appears if the employee is allowed to request an allocation.
The following approval modes are possible:
1. Time Off Officer
2. Employee's Time Off Manager (leave_responsible_id)
3. Employee's Time Off Manager and Time Off Officer
These options are the same as leave approval options
(except the missing "No Validation").
If option 1 or 2 is selected, a o2m field should
allow to select which Time Off Officer is responsible
for approving those allocations.
Allocation approval policy is the same as the leave approval policy.
Task id: 1936742
Access rights based on task 1950998
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Purpose
=======
Having a clean policy in leave access right. If there
are some internal need or bugs, read this before decided
if it is an expected brhavior or not. It is what we want
in a standrard point of vew.
Specification
=============
Access rights Policy
--------------------
Remove Time Off - Team Leader access right
Leave_manager_id is now requried, by default it
is = parent_id for admin it is admin by default (data
employee_admin)
3 access rights:
- Internal User
- Time Off - All Approver
- Time Off - Administrator
3 fields for "manager"
- parent_id
- leave_manager_id
- manager_id on department
Department
Is just there for information. So never use it in
default filters
Rules Policy
------------
Don't forget to take the leave type configuration into
account
* no validation means automatic
* officer validation means you need to be at least
holidays_user to approve
* manager validation means anyone who is at least
leave_manager_id can approve
Internal User
-------------
In double validation mode he:
- can only do the first approval
- can see the everyone's leaves with a anonymisation of
the leave description
- can create a leave (even if leave type is directly approved)
- can refuse its own leaves (till not reported in payslip)
- can reset to draft his own leaves and reconfirm them
- can delete a leave in draft state
- can cancel a leave if the date_start is in the future
- cannot validate its own leaves
If leave type is configured in manager mode, he:
- can approve or refuse the leaves if he is leave_manager_id
If leave type is configured in both mode, he:
- can only do the first approval or refuse for the leave
if he is leave_manager_id
Time Off - All Approver
-----------------------
In double validation mode he:
- can only do the second approval
- can see, write, read all leaves and perform the second
approval.
- Can set a leaves as reported in payslip.
- Cannot validate its own leaves
- cannot configure leave type
- cannot create leaves in batch
Time Off - Administrator
------------------------
In double validation mode he:
- can do all the approvals
- can bypass all leaves (approve or refuse).
- can configure Time Off Types
- can create batch leaves
- can validate its own leaves
Menu
----
- My Time Off (access rights: internal user)
- Dashboard
- Time Off Requests
- Allocation Requests
- My Team (rename into "Everyone", access rights: internal
user. default filters on current year and group by
employee; default view: gantt can switch to list and form)
- Managers
- To Approve (internal user who are leave_manager_id
see and can approve. See only leave he has to approve
(domain))
- Time Off
- Allocation
- All
- Time Off
- Allocation
- Payroll
- Time Off to report.
- Reporting (access right: time off administrator)
- Time Off Analysis
- Report by Department
- Configuration (access right: time off administrator)
Usability
---------
- In all list of "manager menus", add actions to change
status in mass
- In leave type data:
- move Home Working from data to demo data
- There are 2 Paid time off, get rid of the company on
it and share it on all companies (keep only the one
in data)
- Leave type like this:
- Overtime Compensation/compensatory days (keep only
one of both, to avoid having 2 same leaves in
demo data). Validation by: team leader and hr
officer, no validity date
- Paid Time Off 2019. Validation by Team Leader
and Payroll Officer. Remove validity, remove 2019.
- Unpaid. Can be taken in hours. Approved by Payroll
officer and team leader. No allocation needed.
- New leave request: order of leave type in the m2o:
1. leaves where allocation are fixed by rh and remaining
> 0 and allocated > 0
2. leaves where free allocation. Where reaming is > 0
and allocated >0
3. One already taken
4. All other leaves.
- Remove the sequence widget in leave type
- The employee should get a notification when his leave is
refused "Your "leave_type_name_" planned on "start_date"
has been refused"
- from the dashboard calendar, the reset to draft should lead
to edit (avoid user has to click on edit)
- An employee should be notified when a leave is approved
"Your [leave_type_name] on [start date] has been approved"
Leave Dashboard V2
------------------
https://drive.google.com/file/d/1pMCqDlecqM7ngvmhJJdWtkG2_GiXHyIX/view?usp=sharing
Testing
-------
Everything concerning the leave requests has to be tested.
All the access rights have been reviewed and need testing.
Migration
---------
Don't forget to keep the filters in the calendar view (otherwise RIP perfomances and usability)
TaskID: 1950998
closesodoo/odoo#33813
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In demo data, Marc demo was taking a sick leave during the first and
second of the month, the problem is that when the current month starts
with a saturday this leave ends up being placed only during the
week-end hence no leave should have been taken.
In order to avoid having this weird leave, Marc demo will now take three
days of sick leave
closesodoo/odoo#34318
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The two fields of leaves `request_date_from` and
`request_date_to` are not set in demo data.
These fields are displayed in the form view and are
empty.
This commit add values for these fields to have
a nice and complete form view.
This field is a non-sense. By using the same logic, it should be added
to any low level model.
Replace the check by a simple verification of presence of an XMLID.
A more generic opt-in solution should be integrated into ORM.
Partially revert commits 0db0e66e96 and
bbd64c22ab.
See #29257odoo/enterprise#3550closesodoo/odoo#31778
Signed-off-by: Christophe Simonis <chs@odoo.com>
Purpose of this merge is to update main addons and set activity types used
for automated activities as master data. This means they cannot be removed.
Indeed those activity types are used in business flow to generate activities
and removing them may break some flows.
This commit is linked to task ID 1907970 and PR #29257.
Purpose
=======
We need to use an international word to define holidays and leaves, rename everything into Time Off.
Employees needs a good dashboard and leaves summary
Specification
=============
1/ Add a new dashboard: https://balsamiq.cloud/sm5j0d/pg5w04r
Create a new dashboard with a calendar and a summary of all time off and time off request
2/ Rename leaves into Time Off everywhere
3/ Improve general usability
TaskID: 1916871
closesodoo/odoo#29634
The module lacks demo data to have a nice visual display when testing the application
Add allocation requests and leaves request for several employees
TaskID: 1906478
Purpose
=======
- A manager could want to follow only home working of its own department
- A HR officer could want to follow only sick leaves of all dpts.
We have to improve what people follow and how they follow it in the leaves module
Specifications
==============
Subtype on department
---------------------
In department form view, right now, people can follow approvals
Instead we should have some generic and specific subtypes depending on the leave type
For instance, a HR Officer wants to follow only sick leaves and a manager only home working
Following mechanism
-------------------
Remove first / second approval subtype differences
if a leave type is not linked to a specific subtype, consider only classic
people follow it (employee and assigned HR people / manager)
Link leave type to subtypes, with some by default (i.e. home working, ...), not mandatory
When creating a leave type, link it to the department to be able to
activate the subtype for only one department.
Purpose of this commit is to simplify fields used in leave and allocation
used to store the duration of the requests. We want notably to get rid
of "number of days temp" that, contrary to its name, is not temporary
at all as it stores the real number of days. We also want to clarify
the hours or days encoding that is different on leave and allocation models.
Specifications
* number_of_days on leave and allocation is the master field holding the
leave or allocation duration in days;
* two fields are used for interface that are suffixed by _display in order
to indicate they are UX only: number_of_hours_display and number_of_days_
display. They are interface fields used for the user and correct number
of days is computed and stored in number_of_days;
* more specifically for leave model
* display fields are readonly as it is computed based on dates given by
the user, directly (from / to) or indirectly (half-day leaves for example);
* duration field is computed through an onchange. It could be directly
set by hand by managers if some confusion in the number of days appear;
* more specifically for allocation model
* display fields trigger an inverse as they are the real duration given
by HR officers or managers;
* duration field is computed through the inverse of display fields;
Various reports, data and use of leave / allocation models are updated to
use the correct field.
This commit is linked to task ID 1876795 and PR #26571.
Purpose of this commit is to simplify the configuration of leave type and
use the job of HR officers / manager by making options clearer and easier
to use.
Specifications for leave type :
* display name as header;
* remove accrual option from leave type. It is now configured directly
on allocation requests;
* add a "X days allocated" stmart button. If you set a general allocation
of 20 days, the stat button will display 20 days. Even if you go update
the allocation by employee after that. Purpose is to have the value of
main allocation done in group, not individual cases of some employees;
* add a "Group leaves" stmart button. It leads to a new leave requests
in group mode where mode is visible;
* have a unique allocation type field replacing the setting allowing to make
leave or allocation as well as limit and negative fields;
* limit leave duration encoding to two options, either day-based (allowing to
take full days or half a day), either hours-based (allowing to take full
days, half a day or some specific hours in a given day);
More technically
* limit and negative fields are removed. It was confusing as limit set to
True means you can actually exceed the limit). It can be computed based
on allocation_type ('no' meaning you can bypass the limit);
* request_unit is simplified. Day and half are merged into day;
* accrual and balance limit are moved to allocation model;
Specifications for allocation requests
* set accrual specific on allocation itself and not coming from the leave
type configuration anymore. Indeed we now consider accrual to be done
case by case independently from the leave type;
* remove negative and balance_limit. Indeed we now consider people have to
check by hand what is done by accrual;
Leave and allocation are slightly impacted by other changes, such as domain
for default leave types. Changes have been made as small as possible. Future
commits will still improve leave and allocation models and views, going
further in the cleaning process. Some tests are udpated to match the new
configuration of leave type.
This commit is linked to task ID 1876795 and PR #26571.
Demo data prevent from reinitializing hr_holidays module. Indeed confirming
already confirmed leaves or allocations does not work. Demo data are
updated so that we can initialize hr_holidays several times.
This commit is linked to task ID 1876795 and PR #26423.
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
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;
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
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
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.
If an user (or a developer) wants to install this module twice, she
could not before this patch. Because those demo data call a function
that crashes if the state of the demo data has been modified... and
modifies it!
We avoid this issue by resetting the states of the demo data
explicitely (before a deeper refactoring)
addendum to commit da6b9d1be443999028f021ff81b4cf128a4eaaa2
- better employee name and image for default employee in data (xml-id: hr.employee_root)
- in demo data hr.employee_fp renamed to hr.employee_root to not have 2 employees linked to the root user
- renamed all occurences of employee_fp to employee_root
- 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()
Barad Mahendra