CalDAV delegation

Since version 1.4 SabreDAV comes with a calendar-proxy support. This feature allows for calendar delegation.

Calendar delegation allows users to give other people access to their calendars. This can be done either read-only or read-write.

Only entire accounts can be delegated. It's not possible to do per-calendar sharing. This functionality is possible as well using CalDAV sharing.

Client support

iCal, BusyCal and several other clients now support this feature.

So for the moment it's required to manually add delegees using the database, or by directly interfacing with the WebDAV API for this.

Once permissions are granted though, delegated calendars show up in the iCal preferences interface.

Setting up

To make sure delegation works, every single principal that needs this, will need to have two sub-principals.

Example for creating a 'John Smith' account:

INSERT INTO users (username, digesta1) VALUES ('jsmith',MD5('jsmith:SabreDAV:mypassword'));
INSERT INTO principals (uri, email, displayname) VALUES ('principals/jsmith','','John Smith');

-- Now the special principals
INSERT INTO principals (uri) VALUES ('principals/jsmith/calendar-proxy-read');
INSERT INTO principals (uri) VALUES ('principals/jsmith/calendar-proxy-write');

These two sub-principals act as groups.

To allow other users to access John Smiths calendars, they must be added to either the read, or the write group.

You can do this through the groupmembers database table.

Using the correct Principal Collections

You must make sure that for the '/principals' collection at the root of your server, you do not use the following class:

You have to use this instead:

The CalDAV-specific collection ensures that the new proxy principals are correctly created.

Manually giving users access to other accounts

If you want to give user A access to user B's calendars, this means that principal/userA needs to be part of the principal/userB/calendar-proxy-write group.

To do this through the database, you need to look up the id for principal/userA and principal/userB/calendar-proxy-write. You add these id's to the groupmembers table.

The id for principal/userA will become the member_id field value, and the id for principal/userB/calendar-proxy-write should be put in the principal_id field.


This feature is based on the specification published here: