From Davical
Revision as of 13:02, 12 June 2017 by Fsfs (talk | contribs) (reference LDAP group sync settings, caldav scheduling is RFC now)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search



For a general overview on Users, Resources and Groups and some configuration examples please refer to the information given on the DAViCal project website. This page here will only try to deliver some background information to the instructions given on the website.

Essentially the permissions are divided into two parts, from a user perspective:

  • Groups - ways of grouping a set of users together.
  • Grants - ways of providing access to a user, or a group of users.

DAViCal also implements a concept of "default privileges", so that as well as granting specific privileges to a user or group, you may grant privileges to 'everyone'.


A 'group' is in effect any user, although in a normal installation these will be users who are specially set up to mediate between an individual and a set of permissions. The group (or someone with administrative rights to the group) controls who is a member. Groups may also be members of other groups, although multiple levels of nesting can add significant overhead and it is recommended that you keep this shallow.


The permissions which can be granted are fine-grained and directly map to the DAV privileges defined in RFC3744, and to the other privileges from CalDAV and so forth. All permissions are stored as a bitmap, so permission operations & tests are much simpler logical AND or OR operations.

Collection-level Privileges

While grants can still be applied between users, as with relationships in older DAViCal versions, then can now also be applied to collections, so a user might grant more public rights to one [calendar] collection, while restricting access to another.


How do I make new users members of a default group on creation

Prior to 0.9.8 it was possible to make new users automatically be set up with some default relationships. How do I do this now?

  • From 0.9.8 you should configure the targets of any default access to grant privileges by default. This is much more flexible, and means that an individual user might configure an individual calendar to have global access.
  • You can also configure the set of default privileges which are granted by new users (to everyone) by setting the $c->default_privileges value in your configuration file with something like:
$c->default_privileges = array('read-free-busy', 'schedule-deliver');

(i.e. to allow free-busy access from anyone, which is the default). The names of all of the privileges which can be used in the array are listed below.

Note that these default privileges are only what is assigned when a new principal (i.e. a user, group or resource) is created. If you change this default it won't apply to any previously created principals.

How can I translate my LDAP Groups into DAViCal groups

Since 0.9.9, the LDAP driver can sync LDAP groups to DAViCal: Configuration/Authentication_Settings/LDAP_groups

Do members inherit the access rights of the group user?

Yes. Group membership is transitive (each member of a group receives the privileges granted to that group) and additive (if you are a member of several groups, each granted different privileges to the same resource, your effective privileges will include all of the privileges granted to any of the groups you are a member of.

So members of a 'resource administrators' group granted write access to a set of resources might also be members of a 'resource users' group which only has read access granted to it, and the administrators will receive read+write access as a result.

Do other group members gain access to my collections?

Group members will only gain access to your collections if you grant them access to your collections. They won't gain access by default. All access is granted either through explicit Grants by a collection or a principal, or through setting the default privileges on a collection or a principal.

Further Reading

Take a look at Permissions/Examples for some more examples of how to do particular things within the new permissions model, and look into Configuration/settings/default_privileges for details of setting the default privileges granted by new users.

What the Privileges Mean

The DAV permissions are as follows:

  • read
  • write-properties
  • write-content
  • unlock
  • read-acl
  • read-current-user-privilege-set
  • write-acl
  • bind
  • unbind

Some permissions are aggregate:

  • write - aggregate of write-properties, write-content, bind & unbind
  • all - aggregate of all permissions

Since none of those cover what might be desirable for Freebusy there is an additional one defined by CalDAV, which is:

  • CALDAV:read-free-busy

Furthermore, CalDAV Scheduling Extensions to WebDAV (RFC6638) adds several further CalDAV permissions:

  • CALDAV:schedule-deliver-invite
  • CALDAV:schedule-deliver-reply
  • CALDAV:schedule-query-freebusy
  • CALDAV:schedule-send-invite
  • CALDAV:schedule-send-reply
  • CALDAV:schedule-send-freebusy

Two more aggregate permissions are also added with this RFC:

  • CALDAV:schedule-deliver - CALDAV:schedule-deliver-invite, CALDAV:schedule-deliver-reply and CALDAV:schedule-query-freebusy
  • CALDAV:schedule-send - CALDAV:schedule-send-invite, CALDAV:schedule-send-reply and CALDAV:schedule-send-freebusy


Grants basic read access to the principal or collection.


Grants access to update properties of the principal or collection. In DAViCal, when granted to a user principal, this will only grant access to update properties of the principal's collections and not the user principal itself. When granted to a group or resource principal this will grant access to update the principal properties.


Grants access to write content (i.e. update data) to the collection, or collections of the principal.


Grants access to write content (i.e. update data) to the collection, or collections of the principal.


Grants access to read ACLs on the collection, or collections of the principal.


Grants access to read the current user's privileges on the collection, or collections of the principal.


Grants access to writing ACLs on the collection, or collections of the principal.


Grants access to creating resources in the collection, or in collections of the principal. Created resources may be new collections, although it is an error to create collections within calendar collections.


Grants access to deleting resources (including collections) from the collection, or from collections of the principal.


Grants other users the privilege to query my free/busy, via the CalDAV free-busy-query report.


These privileges will typically be granted wholesale within a small busines or workgroup environment, where everyone should be able to schedule meetings.


Grants other users the privilege to deliver invitations to me.


Grants other users the privilege to deliver replies to invitations I sent to them.


Grants other users the privilege to query my free/busy, via the methods defined in the scheduling extensions to CalDAV.


These privileges will typically be granted by a person to their assistant, or to the people in their team, or direct manager, who might be expected to schedule meetings on their behalf. You would expect these to be granted along with the 'write-content', 'bind' and 'unbind' privileges.


Grants other users the privilege to send invitations on my behalf.


Grants other users the privilege to reply to invitations on my behalf.


Grants other users the privilege to send freebusy queries on my behalf.


iCal Does Not See Granted Calendars

Apple iCal only sees delegations at the principal level, so if you are using iCal and you wish to grant access to only a subset of your collections it is necessary to first grant access by default to the principal, and then set narrower privileges on each individual collection which you want to restrict access to.

At present iCal will not see the calendar if you grant a default of restricted privileges at the principal level, and grant broader specific privileges to individual calendars.