View source for Calendar:Feature Implementations:Alarms

<small>[[Calendar:Home_Page|<< Back to Calendar Home Page]]</small>

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 <code>X-MOZ-LASTACK</code> Discussion==
pasted my comment on [http://blogs.sun.com/arnaudq/entry/calconnect_discussion_use_of_valarm#comment-1190979542000 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, <code>X-MOZ-LASTACK</code> is stored inside the <code>VALARM</code> 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 ;) .

===Per-user event alarms===
In a shared calendar environment, users share event information but want to set individual alarm options. User1 setting an alarm on an event should not generate an alarm notification for User2.

Scenario: We use shared calendar files over webdav, where there is a separate calendar file for every user (~25 people, and yes it's slow!), with individual webdav logins but shared read/write access to every calendar file.  We have had to bar the use of alarms because a single alarm record generates notifications for all users.

===Acknowledging alarms===
Assuming that event alarms configuration remains global to all of a calendar's subscribers (not per-user as above), alarm acknowledgment details should probably remain within the client software.  User1 should not be able to 'snooze' User2 and User3, just by being the first to respond.  Keeping alarm acknowledgment details within the client software has the negative implication of the user having to acknowledge the alarm separately in every client software installation, including past events which the user already acknowledged in another client environment.

===Adding alarms to read-only calendars===
The user should be able to set alarms for events in read-only calendars.  Ideally the alarm information would be stored in some network location the user '''does''' have read/write access, so that the alarm information is available across multiple client software.

===Special-handling for alarms on events marked private===
The privacy flag doesn't seem to have much effect in Sunbird/Lightning.  Should it have some effect here?

===Default alarms===
A user should be able to use default alarms, ideally using per calendar defaults. A default alarm on a shared calendar would kick in if no alarm is initially downloaded for an event. The existing Sunbird/Lightning's "Default alarm setting for events" option could work as a global default.