Permissions

Overview
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'.

Grouping
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.

Granting
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?'' $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.
 * 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:

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.

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, 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

read
Grants basic read access to the principal or collection.

write-properties
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.

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

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

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

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

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

bind
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.

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

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

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

CALDAV:schedule-deliver-invite
Grants other users the privilege to deliver invitations to me.

CALDAV:schedule-deliver-reply
Grants other users the privilege to deliver replies to invitations I sent to them.

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

CALDAV:schedule-send
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.

CALDAV:schedule-send-invite
Grants other users the privilege to send invitations on my behalf.

CALDAV:schedule-send-reply
Grants other users the privilege to reply to invitations on my behalf.

CALDAV:schedule-send-freebusy
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.