In fb05d884 event that were not displayed for arabic were fixed but
there could be an error when displaying timezone caused by this change.
As said in https://fullcalendar.io/docs1/event_data/ignoreTimezone/ the
ignoreTimezone parameter is set to `true` by default in FullCalendar 1
(this is not the case in current FullCalendar).
So there is two way to solves this time zone issue:
- keep fb05d884 and have the parameter ignoreTimezone set to `false`
- use momentjs `.toString()` to get a javascript english date string
which will thereafter be parsed by javascript `new Date()`.
This commit use the second way since it is nearer what was originaly and
hopefully safer.
opw-705752
momentjs doc on toString: http://momentjs.com/docs/#/displaying/as-string/
Fullcalendar expect as `start` and `end` property of an event object:
> When specifying Event Objects for events or eventSources, you may
> specify a string in IETF format (ex: "Wed, 18 Oct 2009 13:00:00 EST"),
> a string in ISO8601 format (ex: "2009-11-05T13:15:30Z") or a UNIX
> timestamp.
(as seen in https://fullcalendar.io/docs1/event_data/Event_Object/)
Before this commit we could for example in arabic provide an invalid
date string "٢٠١٧-٠٣-١٦ ١٦:٠٠:٠٦" instead of "2017-03-16 16:00:06".
This commit solves this by always providing fullcalendar an ISO8601 date
string.
opw-705752
The previous code (`parent.field_widget.string`) was returning the untranslated
action name (and why use parent anyway?)
Use the action name instead.
Closes#15207
opw-705938
- Y axis : according to 12 hour or 24 hour format
- Event title : following time format in preferenced language
NB: The conversion from 'A' to 'TT' to match fullcalendar v1 should be
removed when fullcalendar is updated to v2, as the syntax will change.
See : http://fullcalendar.io/wiki/Upgrading-to-v2/
Backport of commit c1d813ec1c
opw-704237
Some buttons in kanban records or event records allowed to open a form
view in edit mode. The feature was lost with commit
https://github.com/odoo/odoo/commit/46857d26#diff-fc48ba68abe25af0106d66b6ea2ec73eL116
Indeed the "do_switch_view" method signature changed but some calls
still used three arguments instead of two, losing the options param.
In case of event not all day, the timezone has an impact.
So if we search for date >= 2016-01-31 (00:00:00) and that the current timezone
is +5, we should search for date >= 2016-01-30 19:00:00.
date_to_str will drop the time.
This commit closes#12878
This commit closes#12971
Commit odoo/odoo@9be7a9535c changes the week number
computation to match calendar and pivot views.
Now, calendar don't use isoWeek format by default, but the weekNumber from locale(),
So we need to adapt also the format for title.
closes#12068, closes#9629
Also:
- keeps unticked filters unticked when deleting a filter or adding a new one
- correctly tick filters when clicking on the partner's name (that code was
broken)
- remove reference to instance.web introduced by a forwardport
- wrong use of self in CalendarView's init()
Before this rev., the events were loaded twice:
- once with the date range as domain (and optionally the content of the search
view),
- once with the date range and the partner_ids of the sidebar's filters (and
content of search view).
The first loading was therefore useless, and might also be very costly.
- Y axis : according to 12 hour or 24 hour format
- Event title : following time format in preferenced language
NB: The conversion from 'A' to 'TT' to match fullcalendar v1 should be
removed when fullcalendar is updated to v2, as the syntax will change.
See : http://fullcalendar.io/wiki/Upgrading-to-v2/
When quickly changing the range in the calendar view, multiple
asynchronous read_slice requests will be launched. The read_slice
returns the records and sets the ids property on the dataset according
to a set domain, context etc.
This creates a race condition because although the read_slice calls will
be launched in the correct order, there is no guarantee that they will
resolve in the correct order. In practice issues will occur quite
frequently on a slower connection and with a big read followed by a
small read. The big read that matches a lot of records will be slower to
complete than the small read which will result in it resolving later
than the small read. This causes the dataset to not be in sync with the
rest of the view. When you click on an affected event everything will
look fine in the popup, but when clicking on edit the form view will
show a new event instead. The reason for this is that switching to the
form view requires a correct dataset.index, which is set by
dataset.get_id_index(id) which won't exist.
A potential way of fixing this would be guaranteeing the order of
read_slice calls by only allowing one of them to be active at a
time. This would not be ideal because you could end up with a long chain
of read_slice calls when changing the range fast on a slow
connection. In theory the UI would have to block as well then.
Instead of that, we will simply ignore responses to out-of-date
requests. This is done by manually resetting the ids property of the
dataset to its previous value when we detect the range of the calendar
has changed since the read_slice call was launched.
opw-673425
To format Week numbers in the pivot view, babel is used with format
`'W'w YYYY` in the current locale (eg: en_US) which will determine
print the week in the locale week numbering type.
This is inconsistant with the fullcalendar version (1.6.4) in Odoo until
at least version 9.0 where ISO is used by default. This behaviour has
been changed in more recent version of fullcalendar and is now in tune
with pivot view, but updating fullcalendar should be done in master.
This commit customize the week numbering on the old version of
fullcalendar getting the yearned result without updating fullcalendar.
This is only possible in saas-6 since momentjs is only present since
saas-6 and is required for this fix.
closes#11522
opw-653671
opw-668711
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.
Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.
The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.
Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
heavy processing.
- Remove view_type attribute from views as it was used to call
fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
lifecycle of widgets (init -> willStart -> start -> destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
action buttons to wrap handlers to ensure that they are executed only if
the form_view is the current active view. This is not useful anymore as
from v9, views and their control panel are appended in the DOM
simultaneously, so one can't click on a button of a view which is not the
current active view.
Commit 516b1a6c72 fixes a bug with action buttons not being displayed when they
should in dialogs. However, it makes the assumption that either $node or
this.options.$buttons exist, which is not always the case (e.g. dashboard).
This rev. moves that logic out of the views to the view_manager, and protects
the call of empty() on this.options.$buttons.
Christophe Simonis