Bug 283252

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