Method `get_day_work_hours_count` can return 0 if no attendance is found
in the calendar. Therefore, we must make sure to not divide by zero,
otherwise, boom boom.
Closes#22900
opw-1815095
Since the method `_get_leave_intervals` assumed that field `tz` is always filled in.
There is a case in default function, when `self._context` had key `tz` but its value was `False`,
which may causes null value of field `tz` and lead to mismatch interval between leave and payslip
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
Purpose
=======
Currently, when creating a company, the resource calendar is created if not specified.
This lead to duplicated data. In Manufacturing > Configuration > Working Time, two same working time demo data('Standard 40 Hours/Week')
Specification
=============
Company should be correctly set in the calendar.
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.
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.
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.
Purpose
=======
A 'Access Rights' (group_erp_manager) user can create a company
A 'Settings' (group_system) user can create a resource.calendar
With the resource module, if a resource.calendar is not set on the new company values, a default one is create.
As the 'Access Rights' user can create a company, but can't create a resource calendar, this should be done with sudo.
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
Christophe Simonis