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.
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.
RomainLibert