Calendar:Feature Implementations:Alarms

<< Back to Calendar Home Page

This page exists to define the best suited alarm behaviour for different use cases and scenarios within the calendar.

Please feel free to add your notes for other alarm behaviours. New designs and use cases can be created which will help give the discussion enough momentum to go the next level.

Alarms for rescheduled events

When an event is rescheduled the associated alarm should move with it.

If an alarm trigger is reached for an event it can be snoozed or dismissed. If the alarm is snoozed and the event is rescheduled before the snooze delay has finished e.g the event is dragged to the next day, the current behaviour is for the alarm reminder to reappear at the end of the snooze delay, showing the new event date.

My suggested behaviour is for the snoozed alarm reminder not to reappear if the event it is attached to has been rescheduled before the end of the snooze delay, but instead to trigger at the originally defined number of minutes/hours ahead of the rescheduled event date.

If an alarm is dismissed and after this the event is rescheduled the alarm should be re-enabled, perhaps after firing a confirmation-dialog.

Alarms On Shared Calendars / Referring To X-MOZ-LASTACK Discussion

pasted my comment on Arnaud's blog here, so it doesn't get lost:

Although I generally appreciate a formal specification of alarm dismissal and snoozing, I am still unsure whether alarm acknowledges (and alarm definitions) ought to be stored within the calendar at all. Considering you subscribe to a public conference calendar, the only chance for alarms you have is to store a copy or import it, so you could write items. On the downside: By doing so, you are decoupled from any updates... It would be really helpful to have some formal guidance how CUAs should handle user [local] data vs. shared data.

Moreover, w.r.t. recurring items, X-MOZ-LASTACK is stored inside the VALARM component of the parent item, to avoid unnecessary creation of exception/overridden items. Thus a single dismiss dismisses essentially all undismissed alarms of the recurring series (from a data model perspective). Quite some users already complained about this. Those users e.g. get three alarms of a series, dismiss only the first, but won't get the latter two again. One could argue that this is not what alarms are meant to be used for and strictly thought the user has acknowledged the item (i.e. what I did in the corresponding bug), but we have to admit that this is real life usage ;) .