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.
New contact from email@example.com to firstname.lastname@example.org Filter on string OttawaMBA to get rid of these messages. Sorry for the spam.
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.
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...
*** Bug 218069 has been marked as a duplicate of this bug. ***
*** Bug 230485 has been marked as a duplicate of this bug. ***
*** Bug 230919 has been marked as a duplicate of this bug. ***
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?
is there *ever* a need for an alarm for events older than today? could they be simply dis-allowed out of hand?
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 :)
(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
(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.
*** Bug 253169 has been marked as a duplicate of this bug. ***
(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.
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.
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.
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.
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. ***
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. ***
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.
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.
....completing. the old allarms have recurrence in the future (repeats every 1 year)
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.
*** Bug 266020 has been marked as a duplicate of this bug. ***
Created attachment 164220 [details] [diff] [review] rev0 - trunk - patch publishes calendar (if so enabled) after acknowledging alarms
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.
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.
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.
Comment on attachment 164470 [details] [diff] [review] rev3 - trunk - All dumps removed, full solid patch including all necessary files Checked in.
Finally fixed. Thanks for the great work lilmatt
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!