Open Bug 486700 Opened 16 years ago Updated 2 years ago

Get rid of capabilities.alarms.popup.supported, think of suppressAlarms

Categories

(Calendar :: Alarms, defect)

defect

Tracking

(Not tracked)

People

(Reporter: dbo, Unassigned)

Details

follow-up from bug 486676: I'd rather see capabilities.alarms.popup.supported go away fully. The alternative is to check if the current alarm capabilities support DISPLAY (popup) alarms, i.e: let alarmValues = this.getProperty("capabilities.alarms.actionValues") || []; if (alarmValues.indexof("DISPLAY") < 0) { // If popup alarms are not supported, automatically suppress alarms ret = true; } Aside from that, we should evaluate what exactly suppressAlarms should do. Some points to consider: * If alarms are suppressed, should the server not notify alarms too? - If so, what if the server doesn't support this? * We don't have icons for suppressed email and sms alarms. - Not needed right now since we don't have a client email alarm service - OTOH needed if we decide that server alarms should be suppressed too. * Looking at the current users of supressAlarms (the most important is the alarm service) I think its feasible to rewrite the conditions to check for (suppressAlarms || !supportsDISPLAYalarms) in the alarm service and possibly fit the conditions in other places.
> * If alarms are suppressed, should the server not notify alarms too? > - If so, what if the server doesn't support this? I think we should scope suppressAlarms (aka Properties "Show Alarms" to the local app. > * We don't have icons for suppressed email and sms alarms. > - Not needed right now since we don't have a client email alarm service > - OTOH needed if we decide that server alarms should be suppressed too. I don't think we should widen suppressAlarms' meaning to anything else than DISPLAY alarms.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.