2
edits
Calendar:Feature Implementations:Alarms: Difference between revisions
Calendar:Feature Implementations:Alarms (view source)
Revision as of 11:32, 8 October 2007
, 8 October 2007no edit summary
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
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. | 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= | ==Alarms for rescheduled events== | ||
When an event is rescheduled the associated alarm should move with it. | When an event is rescheduled the associated alarm should move with it. | ||
| Line 15: | Line 15: | ||
If an alarm is dismissed and after this the event is rescheduled the alarm should be re-enabled, perhaps after firing a confirmation-dialog. | 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= | ==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: | 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: | ||
| Line 21: | Line 21: | ||
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 ;) . | 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 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? | |||