Since the new QWeb engine, `groups` directives on template
rendered in a route with auth=none is simply ignored, since
all is done as SUPERUSER_ID, it was impossible to instanciate
the webclient to check if the session is valid and to display
meeting info or redirect to event form view.
It seems that we don't want to fix this because routes auth=none
are rare, and special. So it is not considered as a bug.
The fix for calendar is, however, to do redirection or template
rendering server side.
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()
When accepting/declining a calendar event invitation received by mail,
we landed on an empty gray webclient. The confirmation page had been
dropped with passage to new JS API / new calendar / new webclient.
Previous mechanism had been reimplemented: custom web client with event
information/confirmation if the user is not connected or redirection to
the event form view if the user is connected.
+ FIX manyattendeetag : the status circle did not turn red when an
user declined the invitation.
- Contact filters were dropped with the new design
- The 'me' filter was not working correctly (wrong colors)
- Remove some useless/unnecessary code
- Use new API confirm dialogs
- Convert CSS to LESS
for compatibility with the enterprise edition.
Also add type=button as the type attribute should always be specified for the
<button> element (different browsers may use different default types).
Improved calendar's favorite meeting list and added a input box to directly
insert the partner in favorite list and 'X' to remove the partner's name
from the favorite meeting list in calendar view.
Jérome Maes