349793 - Creating CalDAV calendar on server not possible

Status: NEW

(Calendar :: Provider: CalDAV, defect)

Description

[Sebastian Schwieger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 BonEcho/2.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 BonEcho/2.0b2

Creating a calendar on a CalDAV server is not possible. There is no error message, however. One would think it has been created. Trying to create an event also gives no error message. But nothing shows up.

Reproducible: Always

Steps to Reproduce:
1.Create a calendar using CalDAV protocol
2.create event in this calendar
3.

Actual Results:  
no error messages, but also no events. No calendar has been created on the server.

Expected Results:  
Calendar should be created, otherwise error messages should popup.

Comment 1

[Sebastian Schwieger]

Forgot build ID again:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060822 Calendar/0.3a2+

Server: Cosmo Server 0.4

Comment 2

[Sebastian Schwieger]

There is an error in the console:

Error: Severe error in internal transaction code!
[xpconnect wrapped (nsISupports, calIItemBase, calIEvent, calIInternalShallowCopy, nsIClassInfo)]
Please report this to the developers.

Source File: chrome://calendar/content/calendar-item-editing.js
Line: 297

using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061002 Sunbird/0.3

Comment 3

[Bruno Browning]

Just to be sure I understand: when you do this the calendar does not exist server-side, and you are expecting Sunbird/Lightning to create it, correct?

Comment 4

[Sebastian Schwieger]

(In reply to comment #3)
> Just to be sure I understand: when you do this the calendar does not exist
> server-side, and you are expecting Sunbird/Lightning to create it, correct?
> 

Exactly. This is the behaviour for ICS/WebDav and I would expect the program to behave consistent in every provider.
Example: home folder is http://server:8080/cosmo/home/username
I subscribe/create to http://server:8080/cosmo/home/username/Calendar and expect Sunbird/Lightning to create "Calendar" in my home folder.

Comment 5

[Bruno Browning]

taking this. patch in progress which depends on another patch currently proposed for bug 355270

Comment 6

[Bruno Browning]

Attachment: implement MKCALENDAR

Patch causes the first call to getItems() to PROPFIND the calendar URI to make sure it exists and is a CalDAV calendar collection, and to attempt to create a CalDAV store at the calendar URI if appropriate. No UI: I think at some point we'll need those annoying "do you want to create it?" dialogboxes, but that's not here yet.

Also fixes bug 360076

The checkDavResourceType function is substantially the same as some code I submitted recently and withdrew for retooling.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Structuring the code this way seems like a violation of modularity in that it's stuffing CalDAV specific code and methods directly into the WebDAV service.  A somewhat better strategy would be to make a calICalDAVService interface that inherits from nsIWebDAVService, and have a C++ implementation in the calendar provider that inherits from nsWebDAVService.  This is still somewhat icky, in that it forces nsWebDAVService to be a public API, but it's cleaner, I think.  I'd suggest reserving a range of method codes for CalDAV-specific stuff in nsIWebDAVListener.idl, and then defining them somewhere in the calendaring code (calICalDAVListener?).

Someday, life gets better when we get around to re-writing the webdav code on top of SAX instead of the DOM for performance.  At that point, we can try and structure things to make it easier for API consumers to hook in their own methods.

Comment 8

[Bruno Browning]

Attachment: patch rev 2 (Look, Ma! No C++!)

Just stashing this for now; will request review after 0.5 ships. There's also significant overlap between this patch and one in bug 374566 which will need to get straightened out.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Bruno, could you pls provide an update on the status of this patch/bug?

Comment 10

[Bruno Browning]

I expect to de-bitrot this patch shortly after 0.8; it will give us basic MKCALENDAR support. But MKCALENDAR is only a small part of what needs to be done in this area, I think. The Create New Calendar wizard really ought to be able to detect the type of a remote calendar instead of relying on the user to choose (bug 306495), and for CalDAV at least I think it ought to detect all the calendars that the user has on the server and which have not yet been registered in Sb/Ltn, and then let the user decide whether to subscribe to one of those or create a new one. 

Comment 11

[Martin Schröder [:mschroeder]]

Assigning to Bruno because there already exists a bitrotted patch. ;)

Comment 12

[Bruno Browning]

Okay, I'll take it. ;)  The previous patch is not just bitrotted, it's the wrong approach in that it MKCALENDARs the calendar collection on first access. When something goes south, this leads to a scenario like:
* user goes through calendar creation wizard to set up CalDAV calendar
* wizard creates provider and pops up dialog saying "Your calendar has been created"
* first access attempts to MKCALENDAR, fails for whatever reason, and the CalDAV provider produces a message like "Unable to create calendar". The dialogs are nicely arranged on-screen so that both messages are visible simultaneously. 8(
So I think this needs to be done in the calendar creation wizard itself, and am setting bug 306495 as a blocker.

Comment 13

[Philipp Kewisch [:Fallen][📱📆]]

We won't block 1.0 on this, but I won't deny a patch for 1.0. Setting wanted+

Comment 14

[Felix Möller]

any news on this? 

The Davical documentation mentions this issue: http://wiki.davical.org/w/Multiple_Calendars

Comment 15

[Philipp Kewisch [:Fallen][📱📆]]

We need some (major) rework on the new calendar dialog for this. To do this right, we need to allow entering just the main server url (i.e https://calendar.myhost.com/) and let DAV detect the calendar collections on that server. We could then add functionality to create a new collection.

This needs to be done in a way so that the dialog can still be used for all providers, and possibly other providers can do the same (i.e google via API would also profit from a calendar selection/creation mechanism)

Comment 16

[Bruno Browning]

Attachment: overly complex ui

I banged together this too-horrible-to-actually-ship calendar-creation-wizard wizardpage as part of allowing the user to:
* discover and use caldav calendars that already exist on the server, owned by the user
* discover and use caldav calendars on the server owned but someone else but with at least 'read' rights delegated
* create a new caldav calendar on the server
I see several possible approaches towards a better UI:
* continue to implement this stuff in the calendar-creation-wizard but apply massive doses of UI-love
* break these three out into separate UI pieces - perhaps a "subscribe to calendar" procedure separate from the calendar-creation-wizard
* abandon the calendar-creation-wizard and add a "Create Calendar Account" to Thunderbird's "Account Actions" UI. This would make plenty of sense for caldav, wcap, and google; less so for ics
* some combination of the above
Would appreciate opinions/discussion before I put further effort into xul.

Comment 17

[Philipp Kewisch [:Fallen][📱📆]]

Hey Bruno, Lenni has some work on caldav autodetection and has proposed some quite simple UI. It uses the calendar-list-widget for displaying the calendars, and I could imagine adding some sections to it for discovering calendars with "read" capabilities. The dialog hasn't gone through UI review yet and there are surely some small tweaks we could do.

His dialog also allows calendar creation with the correct MKCOL requests, we might just need to move the code into the right location (i.e calendar creation in the provider)

If you are planning to make caldav autodetection work better, I'd suggest coordinating work with Lenni. See bug 378873 for the extension he created within the SoC and last I heard he is working on improving the code and moving it into the right locations.

Regarding folding the creation wizard into the Thunderbird account dialog, I agree this makes sense but requires quite a revamp of the calendar manager. I'd rather do this in small steps (autoconfig with old dialog first, then transition to calendar accounts that can have multiple calendars, then transition to integration with the thunderbird dialog).

Comment 18

[Bruno Browning]

Thanks. I knew that SoC work had gone on but not where to find it. Will contact Lenni.

I actually think that doing calendar creation on the provider itself is not the way to go: caldav support needs to be more server/account oriented. My draft code adds calICalDavServer and calICalDavPrincipal ifaces, with calendar creation being done on the latter. The server has a .discover() method that does the bootstrapping; similar methods for other provider types would allow us to modularize calendar-type detection. I'm not sure of the scope of your remarks about the calendar manager. At least initially we could probably avoid a major revamp simply by making it possible for the manager to detect whether two provider instances shared a server.

Comment 19

[Philipp Kewisch [:Fallen][📱📆]]

Oh I didn't specifically mean that it needs to happen on the calendar implementation of the calendar, but rather in i.e calendar/providers/caldav instead of from calendar/base/src somewhere. Lenni wrote the code to make it work with as many caldav and webdav servers as possible first and wanted to take care of moving things around at the end.