Everytime I open my calendar I get alarms for past events

RESOLVED FIXED

Status

Calendar
General
--
major
RESOLVED FIXED
15 years ago
8 years ago

People

(Reporter: Pete Gillis, Assigned: Matthew (lilmatt) Willis)

Tracking

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

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

14 years ago
New contact from mikep@oeone.com to mostafah@oeone.com
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.
Assignee: mikep → mostafah
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.
(Reporter)

Comment 3

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

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

Comment 5

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

Comment 6

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

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

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

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

Comment 9

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

14 years ago
(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

14 years ago
(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.
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

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

Comment 14

13 years ago
(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

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

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

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

13 years ago
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.
This is loosely related to http://bugzilla.mozilla.org/show_bug.cgi?id=257441
*** Bug 257441 has been marked as a duplicate of this bug. ***

Comment 21

13 years ago
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. 
*** Bug 259678 has been marked as a duplicate of this bug. ***

Comment 23

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

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

13 years ago
....completing.

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

Comment 26

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

13 years ago
*** Bug 266020 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 28

13 years ago
Created attachment 164220 [details] [diff] [review]
rev0 - trunk - patch publishes calendar (if so enabled) after acknowledging alarms
(Assignee)

Updated

13 years ago
Attachment #164220 - Flags: first-review?(mostafah)
(Assignee)

Comment 29

13 years ago
Created attachment 164438 [details] [diff] [review]
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.
(Assignee)

Updated

13 years ago
Attachment #164438 - Flags: first-review?(mostafah)
(Assignee)

Comment 30

13 years ago
Created attachment 164457 [details] [diff] [review]
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.
Attachment #164438 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #164457 - Flags: first-review?(mostafah)
(Assignee)

Updated

13 years ago
Attachment #164438 - Flags: first-review?(mostafah)
(Assignee)

Comment 31

13 years ago
Created attachment 164470 [details] [diff] [review]
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.
Attachment #164220 - Attachment is obsolete: true
Attachment #164457 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #164470 - Flags: first-review?(mostafah)
(Assignee)

Updated

13 years ago
Attachment #164220 - Flags: first-review?(mostafah)
(Assignee)

Updated

13 years ago
Attachment #164457 - Flags: first-review?(mostafah)
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 32

13 years ago
taking
Assignee: mostafah → mattwillis
Status: ASSIGNED → NEW

Comment 33

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

Checked in.
Attachment #164470 - Flags: first-review?(mostafah) → first-review+

Comment 34

13 years ago
Finally fixed. Thanks for the great work lilmatt
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
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
The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!
QA Contact: gurganbl → general
You need to log in before you can comment on or make changes to this bug.