Steps :
- Install Planning
- Users > Mitchell Admin > Preferences > Timezone :
Europe/Brussels
- Settings > Employees > Company Working Hours > Timezone :
Japan
- Planning > Gantt View > Week > Mitchell Admin x Friday > Click "+" button
Issue :
- Start date is set by default to Thursday 05:00
whereas it is expected to be set on Friday 00:00
Cause :
- When we want to plan a shift on a day,
we look into the 00:00 to 23:59 range for this day in calendar's tz
to get the closest work time inside of it.
- Yet, this doesn't take the "resource user" into account.
Fix :
- Set these limits for the day in resource's tz.
opw-2678221
closesodoo/odoo#82555
X-original-commit: 1b248ebd58e0a57b070ebf7d67c6da78351a720a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit adds methods to easily obtain calendar validity per resource
for a given search period and get the work intervals per resource,
taking into account the validity of their calendars.
In hr, the create and departure date of an employee are taken into
account to compute the calendars validity.
In hr_contract, it looks for every contract of human resources with
employee of type student or employee existing in the search period and
consider the specific calendar of the contract as valid during the
contract-lifetime.
PR: #77362
task-2646630
The end datetime is not timezoned in _adjust_to_calendar before defining the search_range and using the _get_closest_work_time method.
Since _get_closest_work_time will timezone the timestamp received to start searching, the search interval needs to refer to the same end timestamp to avoid erratic behaviors.
Task-2628876
closesodoo/odoo#79049
X-original-commit: cbf0cb6e210959b3ceea554ec68957416a125141
Related: odoo/enterprise#21915
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Improves on _attendance_intervals_batch to profit more from batching.
Resources are grouped by timezone since we know they will all have the
same result except for when there are resource assigned attendances.
Those have to be handled separately but are incoroporated in the same
routine.
TaskId-2674527
closesodoo/odoo#78741
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Assign a search_range for calendar_end in the _adjust_to_calendar method in all conditions.
The search_range was only assigned a value if the start and end are on the same date before.
The _adjust_to_calendar method receives a start and end from midnight to midnight in the resource timezone.
Start and end datetimes can be set on a different day via the Gantt view set in month or year for example.
This commit ensures that a search_range is always assigned to find the calendar_end and not only when start and end are on the same day.
This allows to find the end of a shift searched over two days if the employee is only working one day.
Task-2628876
closesodoo/odoo#78746
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Time Off : New Dashboard, Accruals feature, Public holidays, New time off type configuration view.
- Review of Dashboard
- Accrual feature : Currently, when you create an allocation, it's possible to create an
Accrual, but there is no appraisal Plan. An Appraisal plan is use to define steps of accruals
for each employee.
In Belgium, we use accrual Allocation for European Leaves, or compensatory hours, it's a
simple use case. But in USA, it's possible to change the calculation mode each year.
Also, in USA, it's possible to deal your accrual plan when you arrive on the company. It's a
HR Officer task to create the right Accrual allocation for each new employee.
- Public Holidays :
Improvement of global time off feature located on Working hours calendar. Now, Time off
application have to manage Public Holidays.
- Review of Time Off type configuration
COM PR: https://github.com/odoo/odoo/pull/72511
ENT PR: https://github.com/odoo/enterprise/pull/19157
UPG PR: https://github.com/odoo/upgrade/pull/2791
TaskID:2475413
closesodoo/odoo#72511
Related: odoo/enterprise#19157
Related: odoo/upgrade#2791
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: William Braeckman <wbr@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
TL;DR
=====
Improve performances with nearly a factor of 2. Use case, call action_validate on hr.leave for 100 employees
- 1987 requests -> 844 requests
- 1300 ms -> 700 ms
Purpose
=======
The first purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The second one is to reduce the number of request for this test.
In term of requests, currently we have:
- 5154 requests without bypassing the mail tracking + the activities management
- 1987 requests when bypassing the mail post-process (this is the current value, the bypassing was
already done several month ago)
- 844 requests with all the optimization done in resource/calendar/hr_holidays
In terms of execution time, we have a reduction from +- 1300 ms to call the method action_validate
to +- 700 ms
As the performances issues severity increases with the number of leaves to create and the real time access
to the database, on the production base, we reduced the execution time to generate more than 500 hr.leaves
from several minutes to 21 seconds. A fix to avoid deadlock was already made at
https://github.com/odoo/enterprise/pull/10740/files
Some contortions were made to avoid changing a signature method in a stable release and thus
introducing for each method a second one, with the "batched" implementation, to keep a retro-compatibility
for the existing custom code.
But surely this could be cleaned in the master version. The old one will be deprecated while waiting to be
removed in a few versions.
closesodoo/odoo#56534
Taskid: 2256705
X-original-commit: 8c96a887d3f05680c923dcd44f9c70c0e5e0bd32
Related: odoo/enterprise#12670
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
With a user with timezone "Europe/Brussels", add a
slot on the gantt view where the preceding day is a working day.
The default starting time will be the previous day.
Reason: the default starting time is midnight, adjusted to
the closest attendance interval in the employee's calendar.
However, midnight in "Europe/Brussels" is actually 10pm UTC
the previous day.
The method adjusting the datetime to the closest attendance only
checks within the corresponding day.
Two ways to fix this:
1) the business code calling `_adjust_to_calendar` should
timezone the datetimes itself. To avoid similar bugs in the future,
the method should be modified to only accept timezoned datetimes.
2) Change `_adjust_to_calendar` to convert datetimes it was given
to the resource's timezone and consider the dates in those converted
datetimes.
Option 2 is chosen because it seems to take care of the problem at a lower
level which allows the business code to not think about those timezone details.
While this is technically an API change (in a stable release), the method was
introduced recently by b058ca1 as a fix for an already broken method.
closesodoo/odoo#53582
X-original-commit: c6cecac60360a1d8b0c62ee155a818a3a28505e1
Related: odoo/enterprise#11399
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The method `_get_work_interval` has several problems:
1) The name is not self explanatory in any way
2) It should be defined on the `resource.mixin`
3) It simply does not work (as described in its docstring).
Here is a simplified example (only concerned about hours):
Currently, given two attendances: 8-12 and 13-17,
with parameters start=9 and end=18 it returns (9, 17)
while it should return (8, 17).
This leads to strange behaviors in the planning app:
Given employee A with calendar 8-17 and employee B 8-16.
Create a planning slot and assign employee A: the start and end times
are set to 8-17.
Then assign employee B, the start and end times are correcly set to 8-16.
Now reassign employee A: the start and end times are not set to 8-17.
Task 2229296
closesodoo/odoo#50804
X-original-commit: 7dfab89bc0025cf6424f00b6992fef1f42463ffe
Related: odoo/enterprise#10426
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Purpose
=======
In Belgium, we need to support some partial time on 2 weeks.
For instance, a mid time, means you could work on monday, tuesday
and wednesday on week1 and monday and tuesday on week 2. Others payroll
softwares manage this.
Specification
=============
Add a checkbox on resource calendar to manage 2 weeks. --> Consider even/odd weeks.
Add sections on calendars (Like sales orders)
Modify methods in resources to apply this behavor generically.
Check that attendances aren't overlapped
Write an integration test for holidays - benefits - payslip
to check all this, + "credit temps" and wage modification.
Note
====
For the sake of simplicity, we only manage calendars over 2 weeks
to consider the odd/even weeks and keep an easy implementation.
For more complicated calendars (eg: over a months with specific targetted days),
it's better to create specific allocation requests and apply specific leaves
for those days, as it would be the case for parental leaves.
closesodoo/odoo#31674
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Buggy example:
I have a 35h working schedule. I work every week day:
- From 8h to 12h
- From 12h to 16h
Let's say that I want to retrieve the working hours from Wednesday 14h03
to Thursday 11h03.
The working hours are:
- From 14h03 to 16h --> 1h57
- From 8h to 11h03 --> 3h03
----------------------------
TOTAL 5h
Currently the result will be 1.95, i.e. 1h57 because the second day
is not taken into account as start time > end time, and thus rrule
doesn't manage this correctly and returns only the datetime corresponding
to the first day.
Specification
=============
Force the until parameter of rrule to be set at the end of the day, do
avoid skipping the second day. Do this in the methods that compute the
work hours and the leave hours.
Add a test to ensure the robustness of the fix.
Closes#21297closesodoo/odoo#28920
The method `plan_hours` does nothing if the `hours` parameter is equal to 0.
This commit adds the 0 case in the logic, and add an optional `resource` in the
parameters.
Example: A workorder works each days between 8am and 4pm. If we call
`plan_hours(0)` at 9pm, we want to get 8am the next day. Currently, it
sends back 9pm.
Before this commit, a hack existed consisting to send a very small value to
`plan_hours`. The holidays and non-working time were taken into account and the
result was rounded to the second. We can now send explicitely 0 and the
non-working hours will be skipped.
Create a resource working 24 hours / day.
If we record it as:
- From 00:00 ; To 24:00 => crash
- From 00:00 ; To 23:59 => 1 minute lost
The `float_time` widget doesn't allow to be more accurate than 1 minute,
therefore it is not possible to record an end time of 23:59:59.999999.
We allow a value of 24:00 which is automatically interpreted as
23:59:59.999999. Only 1 microsecond is lost for such use case, which
should be acceptable for our level of accuracy.
opw-1856943
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.
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
It will enable to retrieve data from the resource module based on a
domain that we pass to the model. It can be used in order to filter on
certain leave types only.
* In resource_mixin and resource add a way to use a domain in order to
filter the leaves
* In resource_mixin add a method to get the work/leaves hours count
We need to check if resource module takes into account the timezone of
the employee taking a leave and the timezone of the user asking to see
when this employee has taken some leave.
Basically everything should be done in UTC internally and then converted
back to the user's timezone.
Purpose
=======
We should add some real timezone support for the global leaves
(resource.calendar.leaves without a resource assigned) currently it is
declared in UTC and never changed to the user or employee timezone.
Specification
=============
In order to support this, we have to add some choices for the user
defining the global leave. He can specify how the timezone is
configured,
- no value is specified, we keep the dates in UTC then convert those to
user timezone
- current user timezone specified, we set the timezone of the leave to
the company timezone
- a timezone is specified, we keep this specific timezone
When we pass two disjoint intervals the behaviour of _interval_and is a
little strange, it returns an interval wich begins after it finishes.
In order to fix that we return None when the intervals are disjoint.
Low-level methods have to convert datetime into a naive user timezone
in order to match the attendances and leaves. Returned values are already
in UTC ready for display. Therefore no postprocessing is necessary for
output.
Planning hours can be done forwards or backwards. In first case the
returned datetime should be the last one aka the date when the job is
finished. In second case it should be the first one, aka the date when
the job begins. Those are the dates user want to know and manipulate when
programming working hours.
Manual forward port of 577eb10c0b .
Planning hours can be done forwards or backwards. In first case the
returned datetime should be the last one aka the date when the job is
finished. In second case it should be the first one, aka the date when
the job begins. Those are the dates user want to know and manipulate when
programming working hours.
Purpose is to replace existing inherits of resource.resource by an inherit
on the mixin itself. The mixin offers several methods to compute working
intervals, attendance, hours, ... This mixin will be improved in future
commits when new methods that will be required with future improvements
of various service apps.
This commit also adds tests for the mixin itself. A new model is defined
only for testing purpose to test the mixin.
Currently timezones were not or incorrectly taken into account in resource
computation. Indeed complexity comes from attendances being expressed in
naive timezones valid for all users, whereas dates and leaves are computed
into UTC. Computation should always be done in user timezone so that there
are no overlapping days and all time intervals are correctly computed.
A new timezone field is added on leaves to know in which timezone they
were originally encoded. Indeed putting them in naive user timezone
require its original timezone, not the current user timezone, as those
can be different.
This commit also contains code cleaning in resource to be a bit more
pythonic, simplify method parameters and offer a more simple api to
other modules.
Eventually code field is removed on resource as it is not really necessary
for resources. It is explicitly added on workcenter model who use it.
Calendar and resource scheduling work on time intervals. However in some
cases it is useful to have info about attendances and / or leaves linked
to those intervals. Internal interval tuples is thus extended to keep
records about resource.calendar.attendance and resource.calendar.leaves.
This will notably allow to remove some hacks in stock_calendar module.
Hooray.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
Companies now always have a default calendar configured. All methods in
resource module should therefore be able to use a real resource.calendar.
This commit removes the computation based on a pseudo 8-17 calendar
given as weird method parameters.
Project is updated in order to use the company calendar by default.
Purpose of this commit is to always have a default calendar for each
company and ensure it is correctly set on resources.
Some cleaning is also performed in resource models to remove unused
fields, improve labels and make views a bit more odoo-ish.
* [REF] res_company: add a m2o to the default calendar to use in the
company as well as a o2m linking all resource calendars used in the
company. Some code has been added to correctly update existing
companies when installing the module;
* [REF] resource_calendar
* [REM] manager field on resource.calendar: this field is never used
and is not necessary anyway
* [ADD] global_leave_ids: filter leaves on a calendar to see global
company leaves
* [IMP] better default company / calendar computation to ensure there
is always a calendar attached to a resource
* [IMP] improve resource and calendar views in order to look more like
other odoo views
This commit cleans resource test code by removing unnecessary stuff
and simplifying code. Purpose is to lessen number of lines and improve
readability of tests. Some duplicated tests have been removed.
Due to an error introduced when migrating the module at new API
at commit a4e57ea16c limited attendances
having date_from and / or date_to were not correctly taken into
account.
Tests have been added to avoid regression.
Audric Onockx (auon)