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 .
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.
- Use the demo resource calendar (40h/week)
- Create a project forecast for the Administrator
- Set the 'Start date' and 'End date' to 2017-07-07
- Plan 8 hours
The % of time should be 100 %, but it's not always the case.
The core of the issue comes from `get_working_hours`.
Case 1:
Call with start_dt = end_dt = 2017-07-07 00:00:00
`get_working_hours_of_date` is called twice with the following start/end
dt:
- 2017-06-07 00:00:00, 2017-06-07 00:00:00 => 0 hours
- 2017-06-08 00:00:00, 2017-06-08 23:59:59.999999 => 8 hours
This is obviously not correct, we don't care about what happens on
2017-06-08. The number of hours is correct in total, but it comes from
the wrong day.
Case 2:
Call with start_dt = 2017-07-07 00:00:00 and end_dt = 2017-07-07 23:59:59
`get_working_hours_of_date` is called twice with the following start/end
dt:
- 2017-06-07 00:00:00, 2017-06-07 23:59:59.999999 => 8 hours
- 2017-06-08 00:00:00, 2017-06-08 23:59:59.999999 => 8 hours
This is obviously not correct either...
We change how the `until` parameter is computed. This way, the correct
call is the second call (Case 2), and `get_working_hours_of_date` is
calld once with the following start/end dt:
- 2017-06-07 00:00:00, 2017-06-07 23:59:59.999999 => 8 hours
opw-745253
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
This commit proposes to add 35 and 38 hours/week resource calendars.
Those are considered as standard for a lot of countries. This helps
users starting with odoo time tracking.
* Remove filter tag
* Use color attribute on the view who add a filter/legend
* Filter is automatically added when 'avatar_field' option is used on a
field tag, and the default template display the avatar.
* Can overwrite the template (add tag template who contains qweb with
<t t-name="calendar-box">...</t>
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
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.
Christophe Simonis