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
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
Create a resource working 24 hours / day.
If we record it as:
- From 00:00 ; To 24:00 => crash
- From 00:00 ; To 23:59 => 1 minute lost
The `float_time` widget doesn't allow to be more accurate than 1 minute,
therefore it is not possible to record an end time of 23:59:59.999999.
We allow a value of 24:00 which is automatically interpreted as
23:59:59.999999. Only 1 microsecond is lost for such use case, which
should be acceptable for our level of accuracy.
opw-1856943