nik/davical
1
0
Fork 0
mirror of https://gitlab.com/davical-project/davical.git synced 2026-05-31 03:34:18 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix the administration overview page to reflect the new permissions.

Browse Source
This commit is contained in:
Andrew McMillan 2009-12-26 00:16:34 +13:00
parent 921926acf5
commit 3bf0c6341e
1 changed files with 70 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

122
docs/website/administration.php
View File

@ -5,99 +5,117 @@
<h1>Administration Functions</h1> <h1>Administration Functions</h1>
<p>The administration of this application should be fairly simple. You can administer:</p> <p>The administration of this application should be fairly simple. You can administer:</p>
<ul> <ul>
<li>Users (or Resources or Groups) and the relationships between them</li> <li>Principals (Users, Resources or Groups)</li>
<li>The types of relationships that are available</li> <li>Membership of groups</li>
<li>Privileges granted by a principal or collection to another principal</li>
</ul> </ul>
<p><i>There is no ability to view and / or maintain calendars or events from within this administrative interface.</i></p> <p><i>There is no ability to view and / or maintain calendars or events from within this administrative interface.</i></p>
<p>To do that you will need to use a CalDAV capable calendaring application such as Evolution, Sunbird, Thunderbird <p>To do that you will need to use a CalDAV capable calendaring application such as Evolution, Sunbird, Thunderbird
(with the Lightning extension) or Mulberry.</p> (with the Lightning extension), Mulberry, Apple iCal, an iPhone or something else.</p>
<h2>Users, Resources and Groups</h2> <h2>Users, Resources and Groups</h2>
<p>These are the things which may have collections of calendar resources (i.e. calendars).</p> <p>These are the things which may have collections of calendar resources (i.e. calendars).</p>
<p>In the list of users you can click on any user to see the full detail <p>In the lists of principals you can click on any principal to see the full detail
for that person (or group or resource - but from now we'll just call them users).</p> for that record.</p>
<p>The primary differences between them are as follows:</p> <p>The primary differences between the types of principal are as follows:</p>
<ul> <ul>
<li>Users will probably have calendars, and are likely to also log on to the system.</li> <li>Users will probably have calendars, and are likely to also log on to the system.</li>
<li>Resources do have calendars, but they will not usually log on.</li> <li>Resources do have calendars, but they will not usually log on.</li>
<li>Groups provide an intermediate linking to minimise administration overhead. They might not have calendars, and they will not usually log on.</li> <li>Groups provide an intermediate linking to minimise administration overhead. They might not have calendars, and they will not usually log on.</li>
</ul> </ul>
<p>These differences are more conceptual than actual, however: in the DAV specification they are really all 'principals' and all equal.</p>
<h2>Types of Relationships</h2> <h2>Groups</h2>
<p>These define the structure of the relationships between users.</p> <p>Groups exist to simplify the maintenance of privileges. Rather than assigning a write privilege
<p>A manager might want to grant full access to their calendar to an assistant, for example, so to each individual with write access, you can create a group with the members being the people
they should create an "Is assistant to" relationship between the assistant and themselves.</p> needing write access, and assign the write privilege to that group.</p>
<p>Relationships themselves are maintained on the User maintenance screen.</p> <p>In this way as people come and go you can maintain the members of the group and it is easier to see
<p>It can also be useful to have several people having the same kind of access to a particular who has the desired level of access. If the needed level of access changes, you can change the grant
set of resources. The "Is a member of group" relationship is used to grant each user access to to the individual group, rather than to each member of the group</p>
the group, and then each resource links to the group with the "Administers Resource" relationship.</p>
<p>You can also define other relationship types beyond the basic ones just described.</p> <h2>Privileges</h2>
<p>Relationship links work in three ways, as follows:</p> <p>The basic DAV permissions are as follows:</p>
<p>read, write-properties, write-content, unlock, read-acl, read-current-user-privilege-set, write-acl, bind &amp; unbind</p>
<p>There are also a couple of useful aggregates of those, which are:</p>
<ul> <ul>
<li>Where users relate to each other (i.e. links to non-group targets), the relationship type will define whether access is free/busy only, read only, <li> write - aggregate of write-properties, write-content, bind &amp; unbind</li>
read &amp; write or full administrative control.</li> <li> all - aggregate of all permissions</li>
<li>Where a set of users link to a group, which does not further link to other users/resources, they will share the same access to each other.</li>
<li>Where a set of users link to a group, which then links to other users/resources, the access restrictions will apply as the lesser of their link to that group, or the link from the group. They will have no access to each other's calendars.</li>
</ul> </ul>
<p>Since none of those covered publication of Free/Busy information, CalDAV introduced an additional <em>read-free-busy</em></p>
<p>Unfortunately that didn't cover all of the possibilities of scheduling privileges, so the
CalDAV Scheduling Extensions to WebDAV has added several further permissions:</p>
<p>schedule-deliver-invite, schedule-deliver-reply, schedule-query-freebusy, schedule-send-invite,
schedule-send-reply, schedule-send-freebusy
</p>
<p>Two more aggregate permissions are also added with this RFC:</p>
<ul>
<li> CALDAV:schedule-deliver - CALDAV:schedule-deliver-invite, CALDAV:schedule-deliver-reply and CALDAV:schedule-query-freebusy</li>
<li> CALDAV:schedule-send - CALDAV:schedule-send-invite, CALDAV:schedule-send-reply and CALDAV:schedule-send-freebusy</li>
</ul>
<p>That's all way too complicated, even if it does need to be there under the covers. Mostly you just need to know
about <em>read</em>, <em>write</em> &amp; <em>free-busy</em></p>
<h3>Some Examples</h3> <h2>Some Examples</h2>
<h4>Several people administer a set of resources</h4> <h3>Several people administer a set of resources</h3>
<p>Suppose you have some resources, R1, R2 and R3 and you want to centralise the booking <p>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 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.</p> have a backup person, so you also want A2 to be able to do that.</p>
<p>In a case like this you should create an intermediate group "G" and set up <p>In a case like this you should create an intermediate group "G" and make each
relationships ("Administers Resource") from "G" to each of the resources to be of the people you want to be able to administer those resources members of that
administered. For each of the people able to administer those resources you group.</p>
should create relationships ("Administers Group") to the group. Other people <p>Each of the resources should be set up to grant default privileges to everyone
who may view the resources, but not change them, can be related to the group to see the full schedule (<em>read</em> privilege), and the resources should be
as "is a member of" which will grant them read only privileges to all of the set up to grant <em>write</em> (or possibly <em>all</em>) privileges to the group "G".</p>
group's resources.</p> <p>In this case you might only set up a single principal for the resources, and have
multiple calendars, one for each resource.</p>
<pre> <pre>
A1 ==>> Administers Group ==> G A1 ==>> is a member of ==> G
A2 ==>> Administers Group ==> G A2 ==>> is a member of ==> G
G ==>> Administers Resource ==> R1 R1 ==>> grants write privilege to ==> G
G ==>> Administers Resource ==> R2 R2 ==>> grants write privilege to ==> G
G ==>> Administers Resource ==> R3 R3 ==>> grants write privilege to ==> G
P1 ==>> is a member of ==> G P1 is a different principal with no specifically granted privilege
P2 ==>> is a member of ==> G
</pre> </pre>
<p>P1 will be able to see all of the scheduled events for R1, R2 and R3, but will <p>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, not be able to create, delete or modify them. A1 and A2 will be able to see,
create and modify all the events.</p> create and modify all the events.</p>
<h4>An administrative assistant has full access to a managers calendar</h4> <h4>An administrative assistant has full access to a managers calendar</h4>
<p>In this case you set a relationship from the administrative assistant <p>In this case the manager will simply grant the desired specific privileges to their assistant.</p>
to the manager of "is Assistant to"</p>
<pre>
A1 ==>> is Assistant to ==> Manager
</pre>
<p>(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 :-)</p>
<h4>A team can see each others calendars</h4> <h4>A team wish to see each others calendars</h4>
<p>In this case you should create a group "G", which all team members are <p>In this case you should create a group "G", which all team members are
linked to as "is a member of".</p> members of, and each team member will grant whatever privileges they wish to that group.</p>
<pre> <pre>
P1 ==>> is a member of ==> G P1 ==>> is a member of ==> G
P1 ==>> grants read privilege to ==> G
P2 ==>> is a member of ==> G P2 ==>> is a member of ==> G
P2 ==>> grants read privilege to ==> G
P3 ==>> is a member of ==> G P3 ==>> is a member of ==> G
P3 ==>> grants write privilege to ==> G
P4 ==>> is a member of ==> G P4 ==>> is a member of ==> G
P4 ==>> grants read-free-busy privilege to ==> G
</pre> </pre>
<h4>A team can modify each others calendars</h4> <h4>A team can modify each others calendars</h4>
<p>In this case you should create a group "G", which all team members are <p>Similar to above, you should create a group "G", which all team members are
linked to as "Administers Group".</p> members of, and each team member will grant <em>write</em> privileges to that group.</p>
<pre> <pre>
P1 ==>> Administers Group ==> G P1 ==>> is a member of ==> G
P2 ==>> Administers Group ==> G P1 ==>> grants write privilege to ==> G
P3 ==>> Administers Group ==> G P2 ==>> is a member of ==> G
P4 ==>> Administers Group ==> 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
</pre> </pre>
<p>Also see the Permissions page on the DAViCal Wiki: <a href="http://wiki.davical.org/w/Permissions" title="The Permissions page on the DAViCal Wiki">http://wiki.davical.org/w/Permissions</a>.</p>
<h1>Configuring Calendar Clients for DAViCal</h1> <h1>Configuring Calendar Clients for DAViCal</h1>
<p>The <a href="clients.php">DAViCal client setup page on sourceforge</a> has information on how <p>The <a href="clients.php">DAViCal client setup page on sourceforge</a> has information on how