From 3bf0c6341e8d2d21000e810ed16d15c752e4039d Mon Sep 17 00:00:00 2001 From: Andrew McMillan Date: Sat, 26 Dec 2009 00:16:34 +1300 Subject: [PATCH] Fix the administration overview page to reflect the new permissions. --- docs/website/administration.php | 122 ++++++++++++++++++-------------- 1 file changed, 70 insertions(+), 52 deletions(-) diff --git a/docs/website/administration.php b/docs/website/administration.php index 56f084b2..f1dc4599 100644 --- a/docs/website/administration.php +++ b/docs/website/administration.php @@ -5,99 +5,117 @@

Administration Functions

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) or Mulberry.

+(with the Lightning extension), Mulberry, Apple iCal, an iPhone or something else.

Users, Resources and Groups

These are the things which may have collections of calendar resources (i.e. calendars).

-

In the list of users you can click on any user to see the full detail -for that person (or group or resource - but from now we'll just call them users).

-

The primary differences between them are as follows:

+

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.

-

Types of Relationships

-

These define the structure of the relationships between users.

-

A manager might want to grant full access to their calendar to an assistant, for example, so -they should create an "Is assistant to" relationship between the assistant and themselves.

-

Relationships themselves are maintained on the User maintenance screen.

-

It can also be useful to have several people having the same kind of access to a particular -set of resources. The "Is a member of group" relationship is used to grant each user access to -the group, and then each resource links to the group with the "Administers Resource" relationship.

-

You can also define other relationship types beyond the basic ones just described.

-

Relationship links work in three ways, as follows:

+

Groups

+

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

+ +

Privileges

+

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

-

Some Examples

+

Some Examples

-

Several people administer a set of resources

+

Several people administer a set of resources

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 set up -relationships ("Administers Resource") from "G" to each of the resources to be -administered. For each of the people able to administer those resources you -should create relationships ("Administers Group") to the group. Other people -who may view the resources, but not change them, can be related to the group -as "is a member of" which will grant them read only privileges to all of the -group's resources.

+

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  ==>> Administers Group    ==> G
-A2  ==>> Administers Group    ==> G
-G   ==>> Administers Resource ==> R1
-G   ==>> Administers Resource ==> R2
-G   ==>> Administers Resource ==> R3
-P1  ==>> is a member of       ==> G
-P2  ==>> is a member of       ==> G
+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.

An administrative assistant has full access to a managers calendar

-

In this case you set a relationship from the administrative assistant -to the manager of "is Assistant to"

-
-A1  ==>> is Assistant to ==> Manager
-
-

(Actually I see there is a bug there in 0.4.0, in that the relationship type -is named the wrong way around as "Is Assisted by", so I'll rename that -in 0.4.1 :-)

+

In this case the manager will simply grant the desired specific privileges to their assistant.

-

A team can see each others calendars

+

A team wish to see each others calendars

In this case you should create a group "G", which all team members are -linked to as "is a member of".

+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

A team can modify each others calendars

-

In this case you should create a group "G", which all team members are -linked to as "Administers Group".

+

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  ==>> Administers Group  ==> G
-P2  ==>> Administers Group  ==> G
-P3  ==>> Administers Group  ==> G
-P4  ==>> Administers Group  ==> G
+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.

Configuring Calendar Clients for DAViCal

The DAViCal client setup page on sourceforge has information on how