350
edits
Changes
no edit summary
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 ;) .
