Sunbird 0.9rc1, OS X
I'm trying to setup a caldav server against moco's zimbra server.
(the URL I found in my iCal setup)
and that didn't work, but gave no indication as to why apart from a yellow warning sign in the calendar list.
mschroeder suggested adding Calendar/, so I tried:
(there's a typo, I know)
a) the spinner never stopped
b) i selected the new calendar and did a 'reload remote calendars' and got:
Warning: There has been an error reading data for calendar: Zimbra@. However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at https://mail.mozilla.com/principals/users/dascher/Calenadar/ is either not a DAV collection or not available
Warning: There has been an error reading data for calendar: Zimbra@. However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description:
Error: thisCalendar is not defined
Source File: file:///Volumes/Sunbird/Sunbird.app/Contents/MacOS/components/calDavCalendarModule.js -> file:///Volumes/Sunbird/Sunbird.app/Contents/MacOS/js/calDavCalendar.js
c) I noticed the typo, so then used:
and I still am not getting any events. All three calendars have an exclamation mark.
Several CalDAV related issues were fixed today. Could you retry with the next Sunbird 0.9 nightly build?
Using URLs in the principals hierarchy is not yet supported. I have draft code that does this successfully which will be submitted in bug 306495 sometime after 0.9 is released. For now you need to use a URL like
as described in bug 450534. I have heard reports of Zimbra installations where the correct URL included a complete email address instead of just a username as in this example. ISTR that the moco install will let you use just a username, but I'm not sure.
I know you've tried, but other moco employees have told me that https://mail.mozilla.com/dav/<username-without-domain>/Calendar works for them.
What you could do is use the program "cadaver" to see if its rather a login problem or that the collection you are looking for doesn't exist.
Then you should get a prompt for user/password and a shell-type prompt where you can type "ls". It should show you a list of collections, similar to:
Listing collection `/dav/Philipp.Kewisch/': succeeded.
Coll: Briefcase 0 Sep 1 03:04
Coll: Calenar 2 0 Sep 1 17:09
Coll: Calendar 0 Sep 1 03:04
Coll: Chats 0 Sep 1 03:04
Coll: Contacts 0 Sep 1 03:04
Coll: Drafts 0 Sep 1 03:04
Coll: Emailed Contacts 0 Sep 1 03:04
Coll: Inbox 0 Sep 1 03:04
Coll: Junk 0 Sep 1 03:04
Coll: Notebook 0 Sep 1 03:04
Coll: Sent 0 Sep 1 03:04
Coll: Tasks 0 Sep 1 03:04
Coll: Trash 0 Sep 1 03:04
Coll: attachments 0 Sep 15 02:33
issuing "propget Calendar" should give you info about that collection, i.e:
dav:/dav/Philipp.Kewisch/> propget Calendar
Fetching properties for `Calendar':
getetag = "1-1220256243000"
getcontentlength = 0
creationdate = 2008-09-01T01:04:03-07:00
calendar-color = #F57802FF
displayname = Calendar
getlastmodified = Mon, 1 Sep 2008 01:04:03 -0700 (PDT)
Which tells you its actually a calendar resource.
Working with David yesterday on irc, it looks like this is not a url issue. The /dav/user/Calendar form works fine, and he's getting a boatload of data returned but not displayed. I filed bug 455260 in response.
In that case I'm marking this bug duplicate of bug 455260 since the url seems fine and the issue should be fixed with the mentioned bug.
*** This bug has been marked as a duplicate of bug 455260 ***