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.
- Converted yml test cases to python unittest
- now, 'self.calendar' recordset from common.py will carry forward its context
so no need to pass context explicitely to the methods calling using that recordset.
- removed commented code
- used odoo.fields.Datetime to covert dates instead of python datetime library
To compute start and end date of a working interval this function replaced
hour in datetime object without taking into account the time zone. The start and end date
taking respectively from calendar_working_day.hour_from and calendar_working_day.hour_to are
in the time zone of the user and the datetime object are compared in UTC to avoid schedule's gap.
This is why the start and end must be converted in UTC after being replaced by these hours.
The tz_info must be removed from dates because it's forbidden to compare naive and aware dates.
opw:648349
Regarding _schedule_days, similar thing was done in
saas-6, @ fd5e7f2.
When the argument `days` was negative, the
returned intervals were wrong.
Regarding `get_working_intervals_of_day`,
calling this method without
`default_interval` and calendar
set crashed.
Closes#8208
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Update views for date_to on calendars
[IMP] Will add a date_to in the calendar attendance and date_from and date_to should be applied/ check backwards also
[IMP] get_attendance_for_weekday will pass date instead of weekday
[IMP] should assign correct procurements in run
xmo-odoo