Closed Bug 432540 Opened 12 years ago Closed 9 years ago

Zimbra CalDav doesn't allow user to dismiss alarms from lightning


(Calendar :: Provider: CalDAV, defect)

Lightning 1.0b2
Not set


(Not tracked)



(Reporter: cmtalbert, Unassigned)





(1 file)

If I have an alarm on my Zimbra CalDav calendar event, it will fire at the appropriate time, however, when I click the "Dismiss" or "Dismiss All" button, nothing happens.  The event is not dismissed, the alarm stays effective and it comes back and alarms again later.

== Workaround ==
Remove reminder from the event in question

== Steps ==
1. Create an event in zimbra caldav with a reminder for ten minutes ago
2. When the alarm dialog comes up, click dismiss

== Expected ==
Alarm is canceled, the alarm dialog disappears

== Actual ==
Nothing happens at all.  Alarm dialog remains, reminder is still active.  No errors are logged.

This is with Zimbra Caldav (not sure if other caldav clients do this) on mac os x (not sure if other platforms do this).

I'm using Lightning 0.8 and Thunderbird version (20080421)
Flags: blocking-calendar0.9?
I see similar behavior with Zimbra calendar in lightning, except
1) when I click 'dismiss' the reminder goes away temporarily.  It pops up again within a short time (haven't determined if the time lag == reminder time.


2) the workaround doesn't work.  A new reminder/alarm is created even if I go in and edit the reminder in lightning.  Removing the reminder from the event using the Zimbra web client does not solve the problem either. 

Annoyingly, this does not affect all calendar events, but I haven't figured out what's special about the ones that do it yet.
Clint, could you retest with Sunbird? There is a similar issue reported in that was fixed after switching from Thunderbird+Lightning to Sunbird.
This appears to be a Zimbra issue; I've filed
(In reply to comment #3)
> This appears to be a Zimbra issue; I've filed

Bruno, the Zimbra bug has been fixed. Can we close this bug now?

According to , the bug has been fixed in 5.0.7 g. a. release. Up to now, latest stable version is 5.0.6.
If someone have access to a development release and can confirm it was a Zimbra fault (i.e. Calendar 0.8 works with this new Zimbra version), bug should be closed.
If it is not a Zimbra fault or it is a shared fault, it should be tested in the new environment to find why alarms can't be dismissed.
Version: Trunk → Mozilla 1.8 Branch
Please reopen this bug if it still shows up.
Closed: 12 years ago
Flags: blocking-calendar0.9?
Resolution: --- → INVALID
I have same problem using Lightning 1.0 beta 2 and Zimbra 5.0.18 server.
(In reply to comment #7)
> I have same problem using Lightning 1.0 beta 2 and Zimbra 5.0.18 server.

As of Zimbra 5.0.7 this should be fixed but I have problems with never version. Maybe is now problem with Lightning ? 

When I am trying to snooze or dismiss alarm a get error popup saying "an error occurred when writing to the calendar X"
(In reply to comment #6)
> Please reopen this bug if it still shows up.

Thunderbird 3.1.3
Lightning 1.0b2
Zimbra 5.0.23

The dismiss buttons never work.  If you tell me how to get error logs and debug messages, I'll happily send them to you.
Resolution: INVALID → ---
OS: Mac OS X → All
Hardware: PowerPC → All
Version: Mozilla 1.8 Branch → Lightning 1.0b2
Confirmed for 
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101208
Lightning/1.0b2 Thunderbird/3.1.7

There has been an error reading data for calendar: Carsten Nielsen. Error code: DAV_PUT_ERROR. Description: Publishing the calendar file failed
Status code: 0
I am also experiencing this issue. The error message I receive is MODIFICATION_FAILED. I am using the following:
Thunderbird 3.1.8
Lightning 1.0b2
Zimbra 7.0.1

Could this bug be related to 459689 as proposed below?
After further testing, I have discovered that this error only seems to appear with events that have an attendee. I've attached the output (MODIFICATION_FAILED_log.txt) from a successful dismissal, a dismissal which pops back up, and a dismissal which then generates the MODIFICATION_FAILED error before popping back up. 

The successful dismissal occurred with an event that had no attendees.
I'm using Thunderbird 3.1.8 on Ubuntu Lucid i686, with Lightning 1.0b2.  I have the same problem, unable to dismiss alarm notifications (mine always fail with MODIFICATION_FAILED).  My company is using some version of Zimbra 6.0 (I *think*, can't figure out how to determine the exact version as an unprivileged user).  I've checked in the Zimbra client, and my most common alarms have zero attendees.

For some reason the error console is not able to load the error description, I don't know if this is part of the symptom or what:

The file view-source:file:///home/trey/.thunderbird/6vscmwdn.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/modules/calUtils.jsm -> file:///home/trey/.thunderbird/6vscmwdn.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/calendar-js/calCalendarManager.js cannot be found. Please check the location and try again.
I am experiencing this same issue with the following profile:

Thunderbird 6.0.1
Lightening 1.0b5
Firefox 6.0.1
Mac OSX 10.7.1

The calendar will pop up the reminders and I will not be able to dismiss all and on some events I will not be able to snooze either.  This manifests for both a single reminder and the entire list.

This is also scene with events have have previously been dismissed and those that are far in the past.

To find out your zimbra server version:

In the main search bar of the advanced (AJAX) web-client enter:
$set:get version

If you are having trouble dismissing events, it could also be that they are recurring events, in this case it is bug 533654, not related to zimbra. This is the case if you get the 409 error as in the attached error console log above.

Since its very likely you are hitting that bug instead of the error with roundtripping X-Props as fixed in the mentioned zimbra bug, I'm going to close this bug again. If you are getting a different error (not a 409 Conflict), then please file a new bug.
Closed: 12 years ago9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.