Closed Bug 405530 Opened 17 years ago Closed 16 years ago

Dismissed alarms re-triggered after remote calendar automatic refresh

Categories

(Calendar :: Alarms, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: pav5088, Assigned: browning)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.6+2.0.0.8-0etch1)
Build Identifier: Mozilla/5.0(Windows;U;Windows NT 5.1;en-US;rv:1.8.1.8pre)Gecko/20071023

  A remote calendar (either CalDAV or iCal - test calendars were hosted on OpenGroupware.org ) will re-trigger dismissed alarms after it is refreshed.

Reproducible: Always

Steps to Reproduce:
1. Subscribe to a CalDAV or iCal remote calendar
2. Add event with alarm - earlier than current time so event will be automatically triggered.
3. Modify Tools/Options/General/Refresh Settings so calendar refreshes every one or two minutes.
4. Dismiss alarm, and observe recurrent alarms after calendar refresh period.
Actual Results:  
Event alarm would always recur after refresh period.

Expected Results:  
A dismissed alarm should remain dismissed even after refresh.

  This was tested using both Sunbird 0.7 and the latest trunk build.  The iCal/CalDAV server was the latest trunk build of OpenGroupware.
  I should also mention that after dismissing every alarm I get an "Item changed on server" dialog.  Is this normal?
https://bugzilla.mozilla.org/show_bug.cgi?id=381573
https://bugzilla.mozilla.org/show_bug.cgi?id=382219

These two other bugs are related to earlier problems I had with alarms on Sunbird/Ogo.  Perhaps there are some clues about what is going on in there.
(In reply to comment #1)
>   I should also mention that after dismissing every alarm I get an "Item
> changed on server" dialog.  Is this normal?
> 

Sunbird's CalDAV provider recently changed the way it checks for changed items on the server; if OGo doesn't properly handle If-Match: headers you'd get that dialog. Just a guess.
I've started seeing this too on the latest nightly branch builds of both Sunbird and Lightning since one of my remote calendar providers upgraded to Zimbra 5.0, which has CalDAV support, and I started subscribing to it via CalDAV rather than ICS.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've seen it too on QA test server (http://rscds.zathras.lss.wisc.edu/caldav.php/mozilla/home/)
Flags: wanted-calendar0.8?
Flags: wanted-calendar0.8? → wanted-calendar0.8+
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Flags: wanted-calendar0.8- → wanted-calendar0.9?
Flags: wanted-calendar0.9? → wanted-calendar0.9+
Is this caldav only?
Flags: wanted-calendar0.9+ → blocking-calendar0.9+
The Zimbra issue mentioned in comment #4 is/was a Zimbra bug: http://bugzilla.zimbra.com/show_bug.cgi?id=28057
I am unable to duplicate this with RSCDS/DAViCal.
WRT OGo, I don't have access to a server, so a packet trace would be useful. Question: is it otherwise possible to modify previously-created VEVENTs on that OGo server?
Assignee: nobody → browning
I am unable to reproduce this on any of Appple Bedework Chandler DAViCal (and I've seen this work properly on Zimbra while investigating the bug mentioned in comment #8, though I don't know if the Zimbra version with the fix has yet been released). Given that this is likely an OGo bug, and that we don't have a straightforward way to get more information our interaction with OGo, I don't think we should block 0.9 on this.
Right, sounds like an OGo bug.
Flags: blocking-calendar0.9+ → blocking-calendar0.9-
Given that this bug appears to be OGo-specific, and that we no longer attempt to support OGo in the CalDAV provider, I'm going to go ahead and close this bug.

->WONTFIX
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.