137772 - [RFE] UI for setting an Alarm (for Schedule, ToDo, Call, Anniversary, etc.)

Status: RESOLVED WORKSFORME

(Calendar :: General, enhancement)

Description

[Peter Lairo]

UI for setting an Alarm (for Schedule, ToDo, Call, Anniversary, etc.)

Screenshot shows suggested UI.

should be able to:
- set/cancel an alarm
- set before or after time or specific date (or accept default)
- set alarm sound (or accept default)
- type a message to be displayed
- enter path to program to be executed

Comment 1

[Peter Lairo]

Attachment: Suggested UI and features for setting alarms.

Comment 2

[Malcolm Rowe]

Why would you want to set an appointment alarm to go off after the 
appointment?  Or at a time unrelated to the appointment?

It would simplify things a lot for the user if you removed the before/after/on 
radio buttons, and the date/time pickers, and just left the two controls to the 
right of the before/after radios, preferably with the text ' before' after the 
duration combo.

Comment 3

[Peter Lairo]

> Why would you want to set an appointment alarm to go off after the 
appointment?  

Because it may not be an "appointment"; it's may be an *event*. For instance, if
you miss a report submittal deadline by more than 14 days, you pay 10% penalty
fee. Therefore, someone might want to be notified 9 days *after* the event to be
able to take mergency actions to avoid the penalty.

> Or at a time unrelated to the appointment?

Sometimes it is useful to be notified of an event on a *specific* date. I have
used this in the past (occasionally).

Of course, the *default* should be "x days before the event", since it is used
the most (but not exclusively).

Comment 4

[Mike Potter]

I won't be doing this.
Anyone who wants to do this can just assign the bug to themselves.

Comment 5

[Robin Edrenius]

This bug is fixed now IMO.

Comment 6

[Joey Minta]

(In reply to comment #5)
> This bug is fixed now IMO.
> 

We are still missing:
(In reply to comment #0)
> should be able to:
> - set specific date
> - type a message to be displayed
> - enter path to program to be executed

It may be open to debate which of these should ultimately be supported, but for
now this is still valid.

Comment 7

[rpe2101]

(In reply to comment #6)
Not to be obnoxious, but I'd definately support the implementation of the "path to program to be executed" feature.

Comment 8

[Simon Paquet [:sipaq]]

Most of the options have been implemented as comment 5 correctly states. The remaining options are either planned to be implemented (specific date/time), have certain security implications (program to be executed) or are better served in a extension (message to be displayed).

Therefore remsolving as WORKSFORME.