212076 - Everytime I open my calendar I get alarms for past events

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Pete Gillis]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

I have some events that have passes and when the initial past alarms shows up I
click...Acknowledge all alarms...this clears up the problem for the current
session, but then next time I open my calendar, they appear again!!

Also, if I disable the alam box, I will still get an email each time as well.

So my expectation is that:

1. Past events should only trigger an alarm once.
2. I don't get alarms unless I have the calendar opened...perhaps its not
possible, but I was hoping to get events anytime mozilla was opened

Reproducible: Always

Steps to Reproduce:
1. Add an event in the past, like a persons birthday
2. enable alarms for the event
3. close the calendar window and open it again

You don't have to close all mozilla windows...it may be important the the event
be recurring...

Actual Results:  
I get alarm events for this past event

Expected Results:  
I should only get the notification once.  I would accept never for past events
if it were the only way, but would rather see them if I haven't already seen
it...like Outlook would.

Comment 1

[Mike Potter]

New contact from [e-mail] to [e-mail]
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.

Comment 2

[Bill Gianopoulos [:WG9s]]

I was having this problem as well.  What was causing my problem was that these
were all recurring events that I had imported into Mozilla Claendar from an
export from another calendar program.  So they each had scads of past
occurences.  I was clicking on the acknowledge butten which only acknowledged
the alarm for one of the past occurances.  I clicked on Acknowledge All so it
acknowledged all the past occurances and that fixed it for me.  So, I am not
sure this is a bug.  However there should maybe be an otion to acknowledge all
past alarms when importing events.

Comment 3

[Pete Gillis]

My guess is that the problem was caused by the fact that I had the remote
calendar refresh everytime I opened the calendar.  Since it is reading a
calendar file each time, it assumes I haven't seen any of the reminders yet. 
The only problem I have with not refreshing is that I could've changed the file
from a different instance, since I have it shared...

Comment 4

[Mostafa Hosseini]

*** Bug 218069 has been marked as a duplicate of this bug. ***

Comment 5

[Mostafa Hosseini]

*** Bug 230485 has been marked as a duplicate of this bug. ***

Comment 6

[Mostafa Hosseini]

*** Bug 230919 has been marked as a duplicate of this bug. ***

Comment 7

[Jon Wright]

I am also able to reproduce this problem with the Mozilla Browser or Mozilla
Thunderbird plugin on both Linux and Windows.

The notification for past events should only appear once (assuming you haven't
snoozed) and the user should certainly not be re-alerted when the calendar is
refreshed from the server.

Does the alarm event have a "user has acknowledged" flag which should be saved
on the server?

Comment 8

[andrew hull]

is there *ever* a need for an alarm for events older than today? could they be
simply dis-allowed out of hand?

Comment 9

[Jon Wright]

I suspect there is a need. For example, if I have an alarm reminding me of a 
birthday a week in advance (might be an odd way to do it, but never mind). And 
I happened to not log in for a day, I'd forget about the birthday and be 
showered with abuse. For this reason alone, it's useful :)

Comment 10

[Andrew]

(In reply to comment #7)
...
> Does the alarm event have a "user has acknowledged" flag which should be saved
> on the server?

The problem of having a flag on the server, is that it would apply to all the 
users who are connected to that calendar.

Perhaps a better thing would be a file on the computer of the user, which tell 
which are the events who have been aknowledged. Then when the calendar updates 
it would automatically check which past events have been aknowledged and show 
the alarms for the ones who havn't be aknowleged

Comment 11

[Jon Wright]

(In reply to comment #10)
> (In reply to comment #7)
> ...
> > Does the alarm event have a "user has acknowledged" flag which should be saved
> > on the server?
> 
> The problem of having a flag on the server, is that it would apply to all the 
> users who are connected to that calendar.

It should be user specific ie. if there are 20 users who acknowledge that event,
the server will store 20 flags saying they've acknowledged it. I feel this
information has to be centralised.

> Perhaps a better thing would be a file on the computer of the user, which tell 
> which are the events who have been aknowledged.

I view calendars from multiple machines, it would be an annoyance to have to
keep acknowledging them.

From understanding the system better, it seems that this isn't really designed
to work in a groupware environment. If you don't update a shared calendar before
adding entries to it, you can inadvertently remove other people's insertions.

Comment 12

[Justin Wood (:Callek)]

in reply to c#11

But why have *so* many flags per-user on a server, where users could be same
name, (you don't know) and you could have anywhere from 2 to 200,000 users
looking at a calendar, thats alot of bloat for one alarm alone!

Use it per computer/profile I say, and if you choose to have "roaming profile"
(once it is set-up better) you can do as you say "multiple computers" and not
have to worry about acknowledging more than once.

There has to be a step between "good for you" and "practical" in a small-user
environment, a practical would be server, especially if any one user has more
than one.

In regards to "users" too, it assumes the server requires a user-login for the
most part.  and in order for said user to store a flag anyway, it assumes that
user has read AND write privs, not always the case...some people can only read a
calendar, and never write to it.  Further strengthening my point on users side,
not server-side.

Comment 13

[Mostafa Hosseini]

*** Bug 253169 has been marked as a duplicate of this bug. ***

Comment 14

[Bob B.]

(In reply to comment #13)
> *** Bug 253169 has been marked as a duplicate of this bug. ***

Bug 253169 describes the problem more accurately and provides a workaround
(publish entire calendar after acknowledgement).  

Since this only applies to remote calendars perhaps the summary of this bug 
should be changed to "Remote calendar alarms won't acknowledge", and the
severity should be raised, as this problem means that alarms *cannot*
realistically be used in a shared calendar environment!

Also, there is a "Private" Flag for the event.. maybe this should be used to
determine "who" can see/acknowledge the alarm.. if its PRIVATE, then alarm
should only show/be acknowledged from the owner of the event.

Comment 15

[Brent Harsh]

I also see this problem, and do not think I am using a remote calendar at all. 
I just installed the calendar into my local copy of Mozilla and started using
it.  I've never published anything.  Yet several times a day (maybe only when a
new alarm triggers) I see a whole host of previously acknowledged alarms appear
as well.  I have gotten into the habit of doing an "ack all" but it doesn't seem
to make a difference - they keep coming back!  My build is 2004080311-cal.

Comment 16

[Telmo Amaral]

My work around for this is: every time that I acknowledge one or more alarms, I
close the Calendar and reopen it (it is not necessary to reopen all the Mozilla
running applications, only the Calendar). Somehow, this “teaches” the Calendar
which alarms have been acknowledged.

Comment 17

[Sander Marechal]

I am using the latest SunBird build as well as the calender plugin for Mozilla
1.7 for Windows, both with shared calenders via our internal webDAV server and I
am getting exactly the same. This bug essentially means that I can't move our
company away from Outlook to Mozilla because we really need shared calenders :-(
I hope it get's fixed fast.

PS: I could not find a separate SunBird category in Bugzilla so I hope
'Calender' is the right place to report SunBird issues as well.

Comment 18

[Sander Marechal]

I have tried fiddling with the settings in calendar and I have found that this
bug only occurs if the "Publish changes automatically" is set on the calendar.
If you manually publish/refresh the calendars then old alarm are not triggered.

Comment 19

[Martin Bagge / brother]

This is loosely related to http://bugzilla.mozilla.org/show_bug.cgi?id=257441

Comment 20

[Simon Paquet [:sipaq]]

*** Bug 257441 has been marked as a duplicate of this bug. ***

Comment 21

[JT Moree]

SINCE you are going to consider my new bug a duplicate of this one--which was
actually a SUGGESTION to fix my own problem buT not the same as this problem--I
am going to post my suggestion here.  

NOTE:  this solution will NOT fix the problem these people are having.  this bug
says that people are getting more than one notice for the same events.  My
suggestion is just asking that really old events be ignored.  That is why I
opened a NEW BUG.

ORIGINAL POST____________________________
Every time I try out mozilla it get nowhere because i try to import my calendar
which I have been using in Korganizer for 3 years or more.  Sunbird/calendar
always barfs and crashes over and over again because of the vast amounts of
alarms being generated.  I get to acknowled a few and then it hangs for a long
time.  Messages popup saying i can kill this script bc it is making mozilla run
slowly and I do.  and so on.

My point is,  I NEVER want to see alarms from Jul 18, 2002.  That is stupid and
uncessary.  The calendar app should have a default period of time that it
ignores alarms if they are before it.  Such as 2 months.

Issues like this have been discussed in bugs like
http://bugzilla.mozilla.org/show_bug.cgi?id=212076
but I dont see this suggestion TO HELP fix the problems. 

Comment 22

[Simon Paquet [:sipaq]]

*** Bug 259678 has been marked as a duplicate of this bug. ***

Comment 23

[Fabien Méghazi]

Is there something in iCal format that could keep the aknowledge status ?
If yes that would be cool, so when you acknoledge an event on your remote
calendar from computer X, when you log on computer Y, it is aware of the
Acknowledge status that has been recorded in the remote calendar.

Comment 24

[Lorenzo Patocchi]

useragent: Mozilla/5.0 (Windows; U; Windows NT5.1; en-US; rv:1.7.2)
Gecko/20040804 Netscape/7.2 (ax)
Calendar: 2004091012-cal

same problems with Ackwnolege request on remote calendar. 

I do report an extra problem starting up the calendar when:
- calendar is remote 
- remote server (where .ics file is stored) require authentication (using Apache
mod_dav)
- old allarms want to pop up for acknowledge

the calendar system get blocked since aknowledge pop up conflicts with
username/password authentication, and starts eating memory increasly.

Workaround: first authenticate to the remote ical server , then open calendar so
that authentication request is in cache and does not conflicts.

Comment 25

[Lorenzo Patocchi]

....completing.

the old allarms have recurrence in the future (repeats every 1 year)

Comment 26

[Matt McDonald]

Here is what worked for me - 
It appears that when you acknowledge an alarm, it doesn't publish automatically.
 That is what causes the problem.  

So to work around the problem, you could publish the calendar manaully every
time you acknowledge an alarm.

Comment 27

[Mostafa Hosseini]

*** Bug 266020 has been marked as a duplicate of this bug. ***

Comment 28

[Matthew (lilmatt) Willis]

Attachment: rev0 - trunk - patch publishes calendar (if so enabled) after acknowledging alarms

Comment 29

[Matthew (lilmatt) Willis]

Attachment: rev1 - trunk - change to prevent repeatedly publishing the same calendar

This patch adds an array that is used when someone selects the "Acknowledge All
Alarms" button. 

The array holds the calendar servers we need to publish the alarm
acknowledgement to, preventing us from publishing to a server multiple times if
more than one alarm is from that server.

This change only affects alarmDialog.js. The other files in the rev0 patch
remain unchanged.

However per irc discussion, we may move the publishing itself to a onClose
function so that the alarm dialog can remain modal, but allow authentication to
publishing servers when necessary.

This patch is posted more for review before things are moved to an onClose
function, than for check in.

Comment 30

[Matthew (lilmatt) Willis]

Attachment: rev2 - trunk - tested, solid version of rev1's array

After much testing and debugging, this is rev1's Ack All Events routine, tested
and solid.

Once we decide whether it moves to onClose or not, we'll know what pieces need
to be checked in.

Comment 31

[Matthew (lilmatt) Willis]

Attachment: rev3 - trunk - All dumps removed, full solid patch including all necessary files

This is a complete patch. It contains all files necessary to squash this bug.
I feel really good about the quality of this one.

Comment 32

[Matthew (lilmatt) Willis]

taking

Comment 33

[Mostafa Hosseini]

Comment on attachment 164470 [details] [diff] [review]
rev3 - trunk - All dumps removed, full solid patch including all necessary files

Checked in.

Comment 34

[Mostafa Hosseini]

Finally fixed. Thanks for the great work lilmatt

Comment 35

[the Real Gerry Grieve]

I get this behavior w "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Mozilla Sunbird/0.3a2" on WinXP.

on launch I import calendar info from a webcalendar server w
"http://www.phas.ubc.ca/WebCalendar-1.0.2/publish.php?user=grieve" & 2 dozen
event (past) notification boxes pop-up.  The "Dismiss All" checkbox remove only 
that particular one.  In "Options"--> "Alarms" I unselected "show missed alarms"
-- not effect.
I unselected "Show alarm boxes" -- no effect

Comment 36

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!