If an event is moved at another time, its appearance would only be
refreshed if it was successful. But in this particular instance, the
refresh may even be more useful when the change failed.
part of #9837
second half of:
opw-657863
As everywhere else, dates & datetimes must be formatted according
to the format defined in the `res.lang` of the user, and within
the timezone of the user.
Before this revision, when adding a datetime field to a calendar view,
the raw value of the date was displayed, for instance:
`2015-01-01 10:00:00`
instead of
`01/01/2015 11:00:00`
for a user in English(US), in UTC +1.
fixes#5324
opw-653625
The calendar has now a minimum height so that it appears bigger in
mobile. In mobile the height cannot be computed to maximum because
the webclient has not 100% fixed height. The height has been set
so that in appears maximum on a 720p android mobile on chrome at
the time of this commit.
The calendar is now also resizing itself correctly after a window
resize.
Before this commit, it was impossible to scroll the calendar
horizontally if needed. Notice that the solution breaks the full
calendar layout and require JS scrolling so that the events are
still positionned correctly.
Calendar height was again a problem since the introduction of the
bootstrap layout (the .row had not height 100% and thus the calendar
was not able to compute its height anymore).
How great is it to get Odoo (almost) 9.0 (almost) translated?
Clean .tx/config file
Regenerate .pot files
Fetch current translations from Transifex (10% completion)
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
Replace deprecate controllers like /web/binary/image, /web/binary/saveas...
Use ETag for all content with 'unique' option to cache the content if the content is never changed.
The start field is a computed field but it doesn't have any inverse function
(write() is overridden in calendar.event to, among other things, play the
role of the missing inverse function). It is thus automatically set as
readonly, and the events can't be dragged and dropped in the calendar view,
since rev. d6d3d098 in which we start checking if the start_date is readonly
or not before allowing the drag and drop.
This rev. simply adds a "do_nothing" inverse function so that the date field
is not readonly.
In web_calendar, the date_start attribute is mandatory so fallbacking on
date_end and date_delay is unnecessary.
Martin Trigaux