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
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
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
Christophe Simonis