Closed Bug 258551 Opened 15 years ago Closed 11 years ago

Alarm should not fire for cancelled event


(Calendar :: Alarms, defect)

Not set


(Not tracked)



(Reporter: anupama, Assigned: brennan.vincent)



(Whiteboard: [good first bug])


(1 file, 1 obsolete file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Build Identifier: sunbird0.2

Alarm should not snooze for a cancel led event. 

Reproducible: Always
Steps to Reproduce:
1. Double Click on an already created event.
2. On the Edit Event screen change Event Status from Confirmed to Cancelled.
Actual Results:  
1. The Edit Event screen is opened.
2. The alarm keeps on occuring on the screen for the cancelled event.

Expected Results:  
1. The Edit Event screen should be opened.
2. The alarm should be disabled for the cancelled event
QA Contact: gurganbl → general
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Component: General → Alarms
QA Contact: general → alarms
Summary: Alarm should not snooze for a cancel led event. → Alarm should not snooze for a canceled event
I can confirm this behavior on both windows and mac with sunbird and lightning respectively.

1. Create a recurring event recurring daily, starting two days in the past
2. Set an alarm on teh event
3. Alarm pops up for the event when you close the event dialog.
4. Click "Snooze" for all instances of the event's alarm, set to snooze for five minutes
5. Edit the event series, change the status to cancel (cancel the entire recurrence)

-- Actual --
Event Alarm pops up after snooze period expires

-- Expected --
If the event is cancelled, there is no need to have an alarm.

Another set of steps to reproduce:
1. Create an event with an alarm
2. Set the event status to "Cancelled"
3. Note that the alarm for the event still fires.

-- Expected -- 
A cancelled event should not fire an alarm.

I think the use case here is that if the user cancels the event, they would not want to be bothered by an alarm for that event. I will change the summary to reflect this and confirm the bug.
Ever confirmed: true
Summary: Alarm should not snooze for a canceled event → Alarm should not fire for cancelled event
The same thing happens when changing the time of an event :
1- create an event and an alarm at  09:00 for instance with alrma 15 minutes before
2- later, change the time to 14:00.

The alarm fires at 0845
OS: Windows 2000 → All
Hardware: PC → All
Duplicate of this bug: 487609
This should be quite easy to do. Anyone willing to step up?
Flags: wanted-calendar1.0+
Whiteboard: [good first bug]
I am a complete beginner to Sunbird hacking, so I'm not promising anything, but this sounds easy to fix indeed, so I will start working on it.
Great! Let me know if you need help setting things up.
Assignee: nobody → brennan.vincent
Attached patch Patch fixing the problem (obsolete) — Splinter Review
Attachment #374487 - Attachment is obsolete: true
Attachment #374488 - Flags: ui-review?
Attachment #374488 - Flags: review?
Comment on attachment 374488 [details] [diff] [review]
Patch fixing the problem

>diff --git a/calendar/base/src/calAlarmService.js b/calendar/base/src/calAlarmService.js
>old mode 100644
>new mode 100755
No need to change mode, 644 is fine.

>     alarmFired: function cAS_alarmFired(aItem, aAlarm) {
>         if (!aItem.calendar.getProperty("suppressAlarms") &&
>+            !aItem.calendar.getProperty("disabled") &&
>+            aItem.getProperty("STATUS")!="CANCELLED") {
>             this.mObservers.notify("onAlarm", [aItem, aAlarm]);
>         }
>     }
> };

Only minimal style nits, we put spaces around operators, see

r=philipp with that changed, I'll fix it before checking in. No ui-review required.

Thanks for the patch, hope to see more from you soon :-)
Attachment #374488 - Flags: ui-review?
Attachment #374488 - Flags: review?
Attachment #374488 - Flags: review+
Pushed to comm-central <> and <>

Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20091106 Calendar/1.0pre
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.