Some caldav clients (most notably Thunderbird with Lightning) don't support the caldav discovery protocol, but insist on all calendar URLs being entered manually. To this end User Interfaces interacting with users will have to show the caldav URL to the user.

Specifically this change adds the property com.openexchange.caldav.url to caldav.properties and adds a new config cascade file meta/caldav.yml to transport the properties to clients.

As an admin, what do I have to do?

If you don't provide caldav functionality to your users, you don't need to do anything (though you should provide caldav, it's awesome!)

If you provide caldav functionality to your users, what you have to do depends on the deployment type you chose. In general you have two options offering caldav to clients:

1) As a virtual host with it's own domain name:

then set the value to the hostname you chose (say 'dav.open-xchange.com'):

com.openexchange.caldav.url=https://dav.open-xchange.com/caldav/[folderId]

2) Via user-agent sniffing:

then use the [hostname] variable in the configuration

com.openexchange.caldav.url=https://[hostname]/caldav/[folderId]

Also, you will have to adjust the user-agent sniffing regex to accomodate new clients (Lightning, in particular). A different entry will deal with that.


As a developer, what do I need to know:

Two new properties are transported to clients in the config tree:

modules/caldav/active determines whether caldav is enabled for a given user
modules/caldav/url contains the value of the path specification in which [hostname] and [folderId] will have to be replaced.