Open Bug 375209 Opened 18 years ago Updated 3 years ago

Decide how to handle alarm on shared calendars

Categories

(Calendar :: Alarms, defect)

defect

Tracking

(Not tracked)

People

(Reporter: mattwillis, Unassigned)

References

(Depends on 1 open bug)

Details

Spin off from bug 355755 > b) how we deal with alarms in shared calendars in the shorter term also > deserves its own bug; let's spin one off for that too.
I would like to propose two options since this bug has been serious trouble in our fully adopting Sunbird. 1. Add an option to every calendar to enable alarms on that calendar. 2. Make one of the differences between "New Calendar . . ." and "Subscribe to Remote Calendar . . ." that "subscribed" remote calendars don't fire alarms but "new" calendars on remote servers still do. Option one sounds more intuitive to me, and seems more global. Option two would need a way to clearly show that alarms wouldn't fire if you subscribed to a remote calendar.
We have option one in the nightliy builds now, it's possible to turn of alarms on or off per calendar.
A somewhat different suggestion is to remove the current option ("Show Alarms") and instead let us choose one of the following for each calendar: 1) Keep alarms on my computer, or 2) Keep alarms in calendar on server This would allow more flexibility. A calendar that's used by only one person could use either option. Option (2) would allow the person to set an alarm at the end of work and receive the alarm at home. A shared calendar could also use either option. The calendar owner could use option (2) while the other subscribers could use option (1). Or they could all use option (2) and share the same alarms. With these choices, it doesn't seem necessary to have a checkbox to completely disable alarms for a calendar. Users could achieve this by choosing to keep alarms locally and then simply not create any alarms.
What if someone decides he/she wants alarms on the server, then with (2) there's still alarms firing for the person who decides he/she wants to have the alarms locally. RFC2445 doesn't have a clear point on how to handle alarms for multiple users, ics-files aren't meant for sharing calendars with alarms, ons should use personal ics-files for that. This means every program has to find a way around it. Keeping alarms locally defeats the idea of using multiple computers with the same settings.
Another worthwhile approach might be to only fire alarms for participants of a calendar event.
Depends on: 861594
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.