Closed
Bug 464133
Opened 16 years ago
Closed 15 years ago
CalDAV deletes against Zimbra server often (always?) fail
Categories
(Calendar :: Provider: CalDAV, defect, P1)
Calendar
Provider: CalDAV
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b1
People
(Reporter: dmosedale, Assigned: Fallen)
References
Details
(Whiteboard: [needed beta][no l10n impact] )
Attachments
(1 file)
3.03 KB,
patch
|
browning
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Flags: tb-integration+
Reporter | ||
Comment 1•16 years ago
|
||
I've managed to unhork my Zimbra server account, and now when I try to delete an event from it, I typically get an error dialog box. The exclamation mark next to the calendar in question appears, and subsequent writes to the calendar seem to fail. The error console sez: Error: An error occurred when writing to the calendar MoCo CalDAV! Error code: MODIFICATION_FAILED. Description: Source File: file:///Users/dmose/Library/Thunderbird/Profiles/7gmvijow.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calUtils.jsm -> file:///Users/dmose/Library/Thunderbird/Profiles/7gmvijow.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js Line: 944
Summary: CalDAV deletes → CalDAV deletes against Zimbra server often (always?) fail
Reporter | ||
Updated•16 years ago
|
Priority: -- → P1
Comment 2•16 years ago
|
||
Depending on bug 458828, this WFM. Tested against momo's zimbra server.
Depends on: 458828
Comment 3•16 years ago
|
||
Dan, since bug 458828 is now fixed, could you please check this again?
Reporter | ||
Comment 4•16 years ago
|
||
Still seems to get the same error, using the most recent build, unfortunately.
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → daniel.boelzle
Comment 5•16 years ago
|
||
WFM against momo zimbra server (URL I am using is like https://mail-test.../dav/dbo/Calendar). However, I think this isn't necessarily an tb-integration issue, but can be investigated towards the release.
Updated•16 years ago
|
Flags: tb-integration?
Flags: tb-integration+
Flags: blocking-calendar1.0+
Reporter | ||
Comment 6•16 years ago
|
||
The way I've been using the tb-integration flag is "I wouldn't want to ship a Thunderbird end-user release containing Lightning until this bug were fixed." If this bug is at all frequently encountered, I'd say that's very much true: deleting an event is extremely basic functionality. In principle, if I were the only user encountering this bug, we could ship without fixing it. There is, however, the more practical concern that as one of the drivers, there's no way I can reasonably make judgment calls about what remains between the current builds and getting something shippable-with-Thunderbird if I can't use the product for typical calendaring use cases. As a result, I don't see how this can avoid being tb-integration+, though you're welcome to try and convince me otherwise. Adding davida to the CC, because I believe he is on the same server instance (MoCo's Zimbra instance) that I am. David, do you see this behavior?
Flags: tb-integration? → tb-integration+
Comment 7•16 years ago
|
||
I never delete, so I don't know. Agree that this would block integration from my POV, until we know who it affects/doesn't affect.
Comment 8•16 years ago
|
||
FYI, i just tried, and i can't delete events. I get a MODIFICATION_FAILED error.
Comment 9•16 years ago
|
||
This is WFM for me as well, against mail-test.momo. Is this problem being seen on that Zimbra instance, or another? If they are different instances, are they the same Zimbra rev? There was at one point a Zimbra bug that caused this kind of thing (incorrect http status returned).
Reporter | ||
Comment 10•16 years ago
|
||
This is against the MoCo server. Pasting "$set:get version" into the Zimbra Web UI search bar shows: Client Version: 5.0.10_GA_2639.RHEL4 Client Release: 20081003014818 Build Date: 20081003-0154 What does the MoMo server instance say?
Comment 11•16 years ago
|
||
The MoMo Zimbra shows: Client Version: 5.0.7_GA_2450.RHEL5 Client Release: 20080630192737 Build Date: 20080630-1935 By setting calendar.debug.log and calendar.debug.log.verbose both to true we could see what status is being returned by the MoCo Zimbra.
Reporter | ||
Comment 12•16 years ago
|
||
Turning on both of those things and then doing a delete results in the following output on stderr: refresh completed with status 207 at https://mail.mozilla.com/dav/dmosedale@mozilla.com/Calendar/ CalDAV: Unexpected status deleting item: 404
Reporter | ||
Comment 13•16 years ago
|
||
Looks like the "refresh" line was actually generated from an earlier action, and only the 404 showed up after the delete.
Comment 14•16 years ago
|
||
Deleting items WFM on latest version gozer has set up (5.0.11_GA_2695.RHEL5-20081117020711).
Comment 15•15 years ago
|
||
I have the same problem in Spicebird. The problem seems to be because of the deleteItem method in dav module getting called twice. The first one is succeeding. The second is failing with 404 error. This was obvious from the Darwin calendar server logs: 2009-01-06 21:06:53+0530 [-] [caldav-8009] [AMP,client] DELETE /calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics HTTP/1.1 2009-01-06 21:06:53+0530 [-] [caldav-8010] [AMP,client] DELETE /calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics HTTP/1.1 2009-01-06 21:06:53+0530 [-] [caldav-8009] [AMP,client] Deleting file /home/bunny/calendarserver/CalendarServer/twistedcaldav/test/data/calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics 2009-01-06 21:06:53+0530 [-] [caldav-8010] [AMP,client] Deleting file /home/bunny/calendarserver/CalendarServer/twistedcaldav/test/data/calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics 2009-01-06 21:06:53+0530 [-] [caldav-8010] [AMP,client] Not found while deleting file: /home/bunny/calendarserver/CalendarServer/twistedcaldav/test/data/calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics The double call seems to be because the UI is making call to deleteOccurences twice. Here are the stack traces for both the calls: #0: function anonymous(aDoNotConfirm=boolean:false, aUseParentItems=boolean:false, aOccurrences=Array:{0}, aCount=integer:1) in <chrome://calendar/content/calendar-views.js> line 182 #1: function onxblkeypress(event=KeyboardEvent:{0}) in <chrome://calendar/content/calendar-multiday-view.xml> line 3775 and #0: function anonymous(aDoNotConfirm=boolean:false, aUseParentItems=boolean:false, aOccurrences=Array:{0}, aCount=integer:1) in <chrome://calendar/content/calendar-views.js> line 182 #1: function deleteSelectedEvents() in <chrome://calendar/content/calendar-views.js> line 646 #2: function cC_doCommand(aCommand=string:"cmd_delete") in <chrome://calendar/content/calendar-common-sets.js> line 229 #3: doCommand: x-jsd:native-code #4: function goDoCommand(aCommand=string:"cmd_delete") in <chrome://global/content/globalOverlay.js> line 86 #5: function oncommand(event=XULCommandEvent:{0}) in <chrome://collab/content/collab.xul> line 1 Because of this, the bug does not occur when backspace key, menu item or toolbar item is used for deletion. It only happens with the delete key. The event deletion always succeeds. I have a strong feeling that this is not Spicebird-only behavior.
Reporter | ||
Comment 16•15 years ago
|
||
Good sleuthing. The fact that the delete key takes a different path than the other UI triggers seems likely to be a bug in and of itself.
Comment 17•15 years ago
|
||
I don't see the key handling code in calendar-multiday-view.xml in hg repo. I also could not reproduce the bug in Sunbird trunk build.
Comment 18•15 years ago
|
||
(In reply to comment #16) > Good sleuthing. The fact that the delete key takes a different path than the > other UI triggers seems likely to be a bug in and of itself. I agree. Who should be in charge fixing that?
Assignee: daniel.boelzle → nobody
Comment 19•15 years ago
|
||
(In reply to comment #18) > I agree. Who should be in charge fixing that? The offending code seems to have been already removed from trunk. Someone who reproduced the bug originally should confirm removal/presence in the trunk.
Comment 20•15 years ago
|
||
Another part of the bug that get reproduced when using the unifinder list view seems to been fixed in bug #449573.
Assignee | ||
Comment 21•15 years ago
|
||
The delete key issue was fixed some time between 0.8 and now, this shouldn't be a problem. Dan, David: I'd like to get this bug finished since its been pending for a while: * Do deletes work magically by now? * Which exact server version is failing - If this version is not the newest stable, I'm tempted to say this bug is INVALID since its a server bug that has been fixed - If this version is the latest stable, please give me access to it. * Does this happen for any type of event, or is there a difference between invitations and normal events - If only for invitations, please invite me to a such event on the account you've given me (see last point, second subpoint)
Reporter | ||
Comment 22•15 years ago
|
||
(In reply to comment #21) > * Do deletes work magically by now? Unfortunately, no. > * Which exact server version is failing > - If this version is not the newest stable, I'm tempted to say this bug is > INVALID since its a server bug that has been fixed Are you certain this is what's going on, or is that an inference based on comment 18? > * Does this happen for any type of event, or is there a difference between > invitations and normal events It definitely happens for normal events; not sure about invitations.
Reporter | ||
Comment 23•15 years ago
|
||
Where I'm seeing the error is indeed the older version mentioned in comment 10.
Reporter | ||
Comment 24•15 years ago
|
||
Current theory is that the upgrade of the server that davida and I use will happen next week.
Reporter | ||
Comment 25•15 years ago
|
||
Unfortunately, upgrading the server doesn't seem to have made any difference.
Updated•15 years ago
|
Whiteboard: [needed beta][no l10n impact]
Comment 26•15 years ago
|
||
I'm also confirming this bug under the Georgia Tech instance of Zimbra and also against the demo server at testzimbra.com, using latest SVN of Sunbird. I'm not an administrator for either server so I don't know their version numbers...I'm just trying to connect to my account on them. This problem does not occur under Evolution. The same error also seems to happen when trying to snooze or dismiss the reminder on a calendar event. This behavior happens whether I connect to the Zimbra server using the CalDAV provider or the iCalendar provider. (With the iCalendar provider, no error is displayed but the requested action does not take place on the server. Adding an event still works fine under iCalendar.)
Comment 27•15 years ago
|
||
Just saw the "$set:get version" trick above. Georgia Tech is running: Client Version: 5.0.13_GA_2791.RHEL5_64 Client Release: 20090206112057 Build Date: 20090206-1128 testzimbra.com is running: Client Version: 5.0.11_GA_2695.RHEL4_64 Client Release: 20081117020633 Build Date: 20081117-0211 I realize that the fact that this issue is occurring under iCalendar may possibly be a separate bug...please let me know. Until today, I have been running a SVN build from late January that has had no problems deleting events from Zimbra under iCalendar. Today I updated to the latest SVN and it's the first time I noticed it doing this under iCalendar. Then I discovered CalDAV support for Zimbra and tried connecting with that, but I'm seeing the same thing all of you are. Looks like the CalDAV issue has been going on much longer though.
Comment 28•15 years ago
|
||
Forgot to mention... this applies to tasks as well as calendar events. Sorry for all the separate messages.
Assignee | ||
Comment 29•15 years ago
|
||
I applied for a testzimbra.com account today, lets see when my mail server actually delivers the email.
Comment 30•15 years ago
|
||
You shouldn't have to wait for an e-mail (at least if you click the "Skip Registration, Go To Demo" button -- I don't know what happens when you click thet other button). Just enter the CAPTCHA and then it will immediately create your account and log you into it. The e-mail in your testzimbra.com inbox will have your username and password for connecting to that inbox in the future and for connecting externally via CalDAV, etc.
Assignee | ||
Comment 31•15 years ago
|
||
aaaah finally I found the problem!!! The following URL will work: http://testzimbra.com/dav/zm308vxujp/Calendar The following URL will not work: http://testzimbra.com/dav/zm308vxujp@testzimbra.com/Calendar The problem lies in the way we strip the path component from the calendar id. Until now we have been using the length of the uri's path /dav/zm308vxujp@testzimbra.com/Calendar/, but the href's returned from zimbra contain just /dav/zm308vxujp/Calendar. Not sure how to best fix this yet, but working on it.
Comment 32•15 years ago
|
||
Great work... if I subscribe to the shorter URL version, that seems to fix it for me too under Georgia Tech's server. But if Zimbra is telling users to use the longer version of the CalDAV URL (as displayed in the Share Calendar dialog), but the software is returing URIs with the shorter version... isn't that a Zimbra issue? I'm asking because I just checked and this problem does not happen on 01.com's Zimbra instance (paid). This is because it has the mail server running on mail.01.com, but its accounts are set up within Zimbra to be in the domain zimbra.01.com. Meaning that when you log in, you have to enter a full e-mail address ending in @zimbra.01.com or the server doesn't recognize the account (really annoying honestly). So in this case Zimbra won't even be able to access the CalDAV calendar if you leave off the @domain part in the URI.
Comment 33•15 years ago
|
||
But ... I guess I can see how this could be a Sunbird problem though, if it should just be handling whatever URI the server gives it back. I dunno. I haven't worked with either of these projects. Just wanted to throw that out.
Assignee | ||
Comment 34•15 years ago
|
||
This should take care. I also noticed a bug when the server redirects (which testzimbra.com did) and added some more code to find such problems quicker in the future.
Updated•15 years ago
|
Attachment #366210 -
Flags: review?(ssitter) → review?(browning)
Comment 35•15 years ago
|
||
Comment on attachment 366210 [details] [diff] [review] Fix - v1 review should be done by someone familiar with caldav provider
Assignee | ||
Comment 36•15 years ago
|
||
I'm sure zimbra could be a bit more forgiving here by not returning a 404 when the default domain is appended, but since the fix on the Calendar side is quite easy, I think we should go for it. Please file a zimbra bug so they can consider doing so.
Comment 37•15 years ago
|
||
Found and updated related Zimbra bug 30263: http://bugzilla.zimbra.com/show_bug.cgi?id=30263
Assignee | ||
Comment 38•15 years ago
|
||
Comment on attachment 366210 [details] [diff] [review] Fix - v1 Daniel, if you have time before Bruno does, please feel free to review.
Attachment #366210 -
Flags: review?(dbo.moz)
Assignee | ||
Comment 39•15 years ago
|
||
Comment on attachment 366210 [details] [diff] [review] Fix - v1 bruno said he'd take care of the review, cancelling request.
Attachment #366210 -
Flags: review?(dbo.moz)
Comment 40•15 years ago
|
||
Comment on attachment 366210 [details] [diff] [review] Fix - v1 looks, works good. =browning
Attachment #366210 -
Flags: review?(browning) → review+
Assignee | ||
Comment 41•15 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/4ce52ce2c749> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Assignee | ||
Updated•14 years ago
|
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•