The administration of this application should be fairly simple. You can administer:
There is no ability to view and / or maintain calendars or events from within this administrative interface.
To do that you will need to use a CalDAV capable calendaring application such as Evolution, Sunbird, Thunderbird (with the Lightning extension), Mulberry, Apple iCal, an iPhone or something else.
These are the things which may have collections of calendar resources (i.e. calendars).
In the lists of principals you can click on any principal to see the full detail for that record.
The primary differences between the types of principal are as follows:
These differences are more conceptual than actual, however: in the DAV specification they are really all 'principals' and all equal.
Groups exist to simplify the maintenance of privileges. Rather than assigning a write privilege to each individual with write access, you can create a group with the members being the people needing write access, and assign the write privilege to that group.
In this way as people come and go you can maintain the members of the group and it is easier to see who has the desired level of access. If the needed level of access changes, you can change the grant to the individual group, rather than to each member of the group
The basic DAV permissions are as follows:
read, write-properties, write-content, unlock, read-acl, read-current-user-privilege-set, write-acl, bind & unbind
There are also a couple of useful aggregates of those, which are:
Since none of those covered publication of Free/Busy information, CalDAV introduced an additional read-free-busy
Unfortunately that didn't cover all of the possibilities of scheduling privileges, so the CalDAV Scheduling Extensions to WebDAV has added several further permissions:
schedule-deliver-invite, schedule-deliver-reply, schedule-query-freebusy, schedule-send-invite, schedule-send-reply, schedule-send-freebusy
Two more aggregate permissions are also added with this RFC:
That's all way too complicated, even if it does need to be there under the covers. Mostly you just need to know about read, write & free-busy
Suppose you have some resources, R1, R2 and R3 and you want to centralise the booking of the resources through an administrative assistant, A1. When A1 is away you want to have a backup person, so you also want A2 to be able to do that.
In a case like this you should create an intermediate group "G" and make each of the people you want to be able to administer those resources members of that group.
Each of the resources should be set up to grant default privileges to everyone to see the full schedule (read privilege), and the resources should be set up to grant write (or possibly all) privileges to the group "G".
In this case you might only set up a single principal for the resources, and have multiple calendars, one for each resource.
A1 ==>> is a member of ==> G A2 ==>> is a member of ==> G R1 ==>> grants write privilege to ==> G R2 ==>> grants write privilege to ==> G R3 ==>> grants write privilege to ==> G P1 is a different principal with no specifically granted privilege
P1 will be able to see all of the scheduled events for R1, R2 and R3, but will not be able to create, delete or modify them. A1 and A2 will be able to see, create and modify all the events.
In this case the manager will simply grant the desired specific privileges to their assistant.
In this case you should create a group "G", which all team members are members of, and each team member will grant whatever privileges they wish to that group.
P1 ==>> is a member of ==> G P1 ==>> grants read privilege to ==> G P2 ==>> is a member of ==> G P2 ==>> grants read privilege to ==> G P3 ==>> is a member of ==> G P3 ==>> grants write privilege to ==> G P4 ==>> is a member of ==> G P4 ==>> grants read-free-busy privilege to ==> G
Similar to above, you should create a group "G", which all team members are members of, and each team member will grant write privileges to that group.
P1 ==>> is a member of ==> G P1 ==>> grants write privilege to ==> G P2 ==>> is a member of ==> G P2 ==>> grants write privilege to ==> G P3 ==>> is a member of ==> G P3 ==>> grants write privilege to ==> G P4 ==>> is a member of ==> G P4 ==>> grants write privilege to ==> G
Also see the Permissions page on the DAViCal Wiki: http://wiki.davical.org/w/Permissions.
The DAViCal client setup page has information on how to configure Evolution, Mozilla Calendar (Sunbird & Lightning) and Mulberry to use remotely hosted calendars.
The administrative interface has no facility for viewing or modifying calendar data.
The DAViCal installation page has some further information on how to install and configure this application.