GNOME Bugzilla – Bug 744927
Don't allow removing event notifications
Last modified: 2015-03-13 15:25:37 UTC
Because in practice they are not removed, they appear again if you click another date and then the one with the event.
That's plan B - according to the design, events should be hidden in the shell when removed.
The design anticipates two behaviours here: * Events in the "today" view (which also shows notifications) act as reminders - they are shown once and can be dismissed. * When browsing other days using the calendar, events should be permanent (since, as Giovanni points out, they do not get removed) - you shouldn't be able to dismiss them, either individually or as a group.
(In reply to Allan Day from comment #2) > The design anticipates two behaviours here: > > * Events in the "today" view (which also shows notifications) act as > reminders - they are shown once and can be dismissed. What does "dismissed" mean here? The underlying calendar does not make any distinction between "events" and "reminders", so the behavior would still just be as described in comment #0 - the list is cleared, but will reappear when the user returns to the main view.
(In reply to Florian Müllner from comment #3) ... > > * Events in the "today" view (which also shows notifications) act as > > reminders - they are shown once and can be dismissed. To clarify, "shown once" wasn't really necessary in that sentence. The can be viewed multiple times, but are hidden once dismissed. > What does "dismissed" mean here? "Isn't shown in the shell UI again." ?
(In reply to Allan Day from comment #2) > The design anticipates two behaviours here: > > * Events in the "today" view (which also shows notifications) act as > reminders - they are shown once and can be dismissed. I have working patches for this (hide events permanently from the shell) locally, but am still waiting for some feedback/guidance for the calendar bits. However ... > * When browsing other days using the calendar, events should be permanent > (since, as Giovanni points out, they do not get removed) - you shouldn't be > able to dismiss them, either individually or as a group. ... this part is ready and independent from the rest, so attaching patches now (on top of bug 746027, which touches some related message list oddities)
Created attachment 299211 [details] [review] calendar: Minor cleanup As the design calls for slightly different behavior for the current day, move the _isToday() function out of MessageListSection to have it available elsewhere as well ...
Created attachment 299212 [details] [review] calendar: Factor out a proper EventMessage class While messages in the EventsSection are currently simple enough to use the generic Message baseclass, the design calls for events to only be dismissable on the current day. We will need a subclass to implement this behavior cleanly, so add one.
Created attachment 299213 [details] [review] calendar: Only allow closing events on the current day The design calls for differentiating between dismissable reminders and permanent events, based on whether the selected date is "today" or some other day.
Review of attachment 299211 [details] [review]: OK
Review of attachment 299212 [details] [review]: OK. You will extend this one for the "hide if today" case right?
(In reply to Carlos Soriano from comment #10) > OK. You will extend this one for the "hide if today" case right? Yeah, see next patch :-)
Review of attachment 299213 [details] [review]: AH! yes =)
Attachment 299211 [details] pushed as d48d787 - calendar: Minor cleanup Attachment 299212 [details] pushed as d1efc27 - calendar: Factor out a proper EventMessage class Attachment 299213 [details] pushed as 01b51cd - calendar: Only allow closing events on the current day
Created attachment 299328 [details] [review] calendar-server: Give each event an unambiguous ID Each event returned by GetEvents includes the (currently unused) UID, which is not always enough to unambiguously identify an event (different calendar sources, recurring events, ...). As we will start using the property to record events that have been dismissed and should be persistently hidden from the calendar, change it to a truly unique ID.
Created attachment 299329 [details] [review] calendar: Permanently hide dismissed events Currently dismissed events will simply reappear when browsing back and forth between dates, which is clearly broken. Instead, hide events that have been dismissed permanently. For now, we simply store a list of ignored IDs ourselves, until we get API in evolution-data-server to reliably store custom per-event properties.
Review of attachment 299328 [details] [review]: OK
Review of attachment 299329 [details] [review]: OK
Attachment 299328 [details] pushed as 8aeebbb - calendar-server: Give each event an unambiguous ID Attachment 299329 [details] pushed as 777616d - calendar: Permanently hide dismissed events