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.
When encoding global leaves, we put the timezone of this particular
leave to False, which raises an exception when given directly to pytz.
Simple solution is to pass 'UTC' in case we receive False. This
behaviour might be improved in master later.
When copying a record implementing the resource mixin, the linked
resource should be copied too and not shared across the records.
Fixes#20956
opw-781508
If TZ is not set on a user, the creation of a `hr.leave` won't populate
the `tz` field of the associated `resource.calendar.leaves` record.
However, the method `_get_leave_intervals` assumes that field field is
always filled in.
Set the TZ to UTC as a fallback.
opw-777031
https://bugs.python.org/issue13936
That's a pretty sensible change, but it turns out we did have some
bits of resource which implicitly depended on the old behaviour.
In Python 3 round:
* rounds half to even (banker's rounding) rather than up
* returns an int if not given a precision (or given a precision of
None)
* discards the negative sign when rounding to 0
Add a compatibility shim which implements P2 behaviour and at least
allows passing float_utils's tests.
Implementing float_round on top of Decimal was attempted but did not
work: although Decimal.quantize takes a non-integral
Decimal (e.g. ``d.quantize(D('0.001'))``) it only supports integral
powers of 10 and does not support quantizing to e.g. 0.05: while that
will not fail it will just use the exponent for quantization and 0.05
is thus equivalent to 0.01, which is not what we want if e.g. need to
round a value to 5 cents.
This is hinted at but maybe not clearly spelled out by the official
documentation:
> Return a value equal to the first operand after rounding
> and **having the exponent of** the second operand.
Also convert a bunch of hand-rolled currency rounding to just using
the round() method on res.currency.
https://bugs.python.org/issue13936
That's a pretty sensible change, but it turns out we did have some
bits of resource which implicitly depended on the old behaviour.
In Python 3 round:
* rounds half to even (banker's rounding) rather than up
* returns an int if not given a precision (or given a precision of
None)
* discards the negative sign when rounding to 0
Add a compatibility shim which implements P2 behaviour and at least
allows passing float_utils's tests.
Implementing float_round on top of Decimal was attempted but did not
work: although Decimal.quantize takes a non-integral
Decimal (e.g. ``d.quantize(D('0.001'))``) it only supports integral
powers of 10 and does not support quantizing to e.g. 0.05: while that
will not fail it will just use the exponent for quantization and 0.05
is thus equivalent to 0.01, which is not what we want if e.g. need to
round a value to 5 cents.
This is hinted at but maybe not clearly spelled out by the official
documentation:
> Return a value equal to the first operand after rounding
> and **having the exponent of** the second operand.
Also convert a bunch of hand-rolled currency rounding to just using
the round() method on res.currency.
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 .
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
A lot of methods are designed to work with pure datetime objects as args. If
the value comes from the database it will be rounded at the level of seconds
(0 microsecond). If it comes from a call do datetime.now() / datetime.utcnow()
the datetime object has a value != 0 for its mircroseconds attribute. Therefore
some methods have unpredictable results depending of the origin of the values
manipulated since the microsecond argument is missing into all the calls to
datetime.replace
Closes#15768
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.
Tomorrow never dies; however no need to add its working hours today.
Indeed rrule until parameter is inclusive. This means that in
current implementation next day is included in computation. This commit
fixes that.
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
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.
RomainLibert