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)
Calendar
Alarms
Tracking
(Not tracked)
NEW
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.
Reporter | ||
Comment 1•16 years ago
|
||
> * 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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•