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

NEW
Unassigned

Status

Calendar
Alarms
9 years ago
9 years ago

People

(Reporter: dbo, Unassigned)

Tracking

Details

(Reporter)

Description

9 years ago
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

9 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.
You need to log in before you can comment on or make changes to this bug.