Version: 4.7 (using KDE 4.7.1) OS: Linux I try to access an ownCloud server using the caldav protocol. The server works, the calendar resources are valid and usable in other clients. However I fail to finish configuring a DAV groupware resource because no collections are offered when accessing the server. Without these the wizzard cannot save the configuration (which makes sense). The same wizzards succeeds to access a carddav collection on the same server. I tried to connect to two other owncloud instances and got the same result. A contacted a few other users and we confirmed that their akonadi succeeded in using the same caldav resources. My conclusion: - the server is working fine - if serves valid and usable caldav resources - akonadi in version 4.7.1 is "normally" able to use these => this bug _might_ be a problem of the opensuse rpm I am using, though this is not sure. It might as well be a kde bug if my version is slightly older or younger than the versions other users use (using other distros) Reproducible: Always Steps to Reproduce: define a new DAV resource (or use an existing one) and add a url to a caldav server. Actual Results: The "fetch" button triggers the connection, the server logs show the requests and results as expected (401 followed by a 207 for each attempt). However no collections are offered afterwards, though these exist and are usable by other clients. Interesting detail: the same wizzard works for the carddav protocol using the same server. Expected Results: The collections to be found, recognized and offered.
Ok, solved the issue (in a way)... I realized that the wizzard does not offer any collection, if there is no entry in the calendar. The moment I made a test entry the collection showed up. I still dont see that calendar in korganizer, but that is another story. I dont want to set this entry to "fixed", since this still is an issue in my eyes, though less important. It still is an issue since the calendar does exist, even if it is empty. Also, now all three available calendars are shown as collections though only one received a test entry. This is a little confusing :-)
Hi Christian, Thanks for your debugging. Have you tried listing the calendars with another client, or accessing their URL directly with a web browser before creating this event? I ask because I've done a debug session on IRC with another ownCloud user who kindly created me an account on his server, and the calendar was not created by default from a DAV point of view. If now you remove this only element, do the calendar disappears? I've just tested creating an empty calendar on my Davical server and it's showing up just fine. Eventually if you want you can catch me on IRC (Freenode, #akonadi, ask for gregueuh). I'm available in the evening (CEST) to test. Cheers, Grégory
Sorry not to mention this in the first place: I did successfully access the collections (calendars) using a standard web browser. I got valid results, calendards for the two existing users did show up. So I assume the calendars did exist whilst trying to access them usin akoadi. Also in my eyes this assumption is confirmed by the fact that according to the server log files akonadi was given valid return codes (207) for the specific collections upon request. This would not have been the case for non-existing collections. Removing the single entry does not remove the collection as being detected by akonadi. This indeed suggests that the collection did not exist before the creation of the test entry. Hm. I am certainly willing to provide more information upon request, but I will not start a huge debugging session myself, since I am busy in my own projects :-)
I have this behaviour on KDE 4.7.2 (packaged as kdepim-runtime-4.7.2-5.fc16.x86_64). The server in this case is Zarafa. I see the PROPFIND requests in the server log, a 401 followed by a 207, but no collections are available, whether there are events in the calendar or not (I added one just to check). I can use this calendar read only by adding an old-style calendar-in-remote-file resource, fetching it manually with a web browser gives me a perfectly reasonable calendar file I can import into other things, and I've checked that thunderbird-lightning can use it without problems.
Hi, Given your version and distro it's more likely that you're hit by another bug: https://bugs.kde.org/show_bug.cgi?id=283615 Cheers, Grégory
If #5 was addressed to #4, then I'm pretty sure I don't have that other bug. I have no form of crash, and nothing like the log messages mentioned in that bug. /usr/bin/akonadi_davgroupware_resource When I go into Korganizer and go to Settings->Configure Korganizer->General->Calendars, I see my Zarafa resource there. I select it and click "Modify" I select the "Caldav" protocol and click "Edit" Up comes a dialog called "Zarafa of type DAV groupware resource" I enter the password as it keeps forgetting it (probably because I can never hit the "OK" button), and click "Fetch" The ssl_access_log on my server says (as soon as I hit the button): 2004:8b1:1641:1::1 - - [17/Oct/2011:21:29:05 +0100] "PROPFIND /caldav/username/ HTTP/1.1" 401 - 2004:8b1:1641:1::1 - - [17/Oct/2011:21:29:05 +0100] "PROPFIND /caldav/username/ HTTP/1.1" 207 45200 2004:8b1:1641:1::1 - - [17/Oct/2011:21:29:05 +0100] "PROPFIND /caldav/username/ HTTP/1.1" 401 - 2004:8b1:1641:1::1 - - [17/Oct/2011:21:29:05 +0100] "PROPFIND /caldav/username/ HTTP/1.1" 207 46965 And nothing else happens. The only available option at this point is to hit "Cancel" Any interesting debug I can attempt?
Meant to say in #6 that /usr/bin/akonadi_davgroupware_resource is happily running. Cut/paste error.
This means that the resource is not able to find the elements that define a calendar in the response from Zarafa, or that they are not here. If you can sniff the trafic and extract the requests/responses between the resource and the server this would definitely help. Cheers, Grégory
Created attachment 64677 [details] HTTP conversation (text) Here's what wireshark says about the conversation between akonadi_davgroupware_resource and Zarafa
Thanks for the transcript. Here Zarafa is not properly handling the Depth header sent by the resource, and it should return both the properties on the requested element (/caldav/tim/) and its first level children. There's nothing that can be done by the resource without breaking other things. You can file a bug at Zarafa for this behavior. Cheers, Grégory
For the benefit of future web searchers, filed against the Fedora Zarafa component as https://bugzilla.redhat.com/show_bug.cgi?id=747241 I couldn't work out how to file a bug at Zarafa's bugtracker, so I'm hoping the Fedora package maintainer has better mojo :-)
And also for the benefit of future web searchers, this is fixed in Zarafa 7.0.2
Hi, Back to the original ownCloud issue, I finally managed to find some time to install one instance and test. The problem here is that ownCloud does not inform the resource that the collections are calendars, so it's impossible for it to know that they must be reported back to Akonadi. However the collections are correctly returned as calendars once at least one event was created inside. Closing as it's not in the resource. Cheers, Grégory