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
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
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.
In resource.calendar.attendance, we store the start and end hour of an
interval as floats.
eg: 17 hours 9 minutes is stored as 17.15
When converting this float to a datetime object, the method
float_to_time always rounds down the value, which may be wrong if, due
to float imprecisions, 0.15 hours is converted to 8.999... minutes (and
was then rounded to 8).
We do fix this behaviour by rounding to the closest integer.
Thanks to @jem-odoo for his help troubleshooting this issue.
opw-1872166