Open Bug 486700 Opened 15 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.