docs/website/administration.php

   1 <?php
   2  $title = "Administration";
   3  include("inc/page-header.php");
   4 ?>
   5 <h1>Administration Functions</h1>
   6 <p>The administration of this application should be fairly simple.  You can administer:</p>
   7 <ul>
   8 <li>Principals (Users, Resources or Groups)</li>
   9 <li>Membership of groups</li>
  10 <li>Privileges granted by a principal or collection to another principal</li>
  11
  12 </ul>
  13 <p><i>There is no ability to view and / or maintain calendars or events from within this administrative interface.</i></p>
  14 <p>To do that you will need to use a CalDAV capable calendaring application such as Evolution, Sunbird, Thunderbird
  15 (with the Lightning extension), Mulberry, Apple iCal, an iPhone or something else.</p>
  16
  17 <h2>Users, Resources and Groups</h2>
  18 <p>These are the things which may have collections of calendar resources (i.e. calendars).</p>
  19 <p>In the lists of principals you can click on any principal to see the full detail
  20 for that record.</p>
  21 <p>The primary differences between the types of principal are as follows:</p>
  22 <ul>
  23 <li>Users will probably have calendars, and are likely to also log on to the system.</li>
  24
  25 <li>Resources do have calendars, but they will not usually log on.</li>
  26 <li>Groups provide an intermediate linking to minimise administration overhead.  They might not have calendars, and they will not usually log on.</li>
  27 </ul>
  28 <p>These differences are more conceptual than actual, however: in the DAV specification they are really all 'principals' and all equal.</p>
  29
  30 <h2>Groups</h2>
  31 <p>Groups exist to simplify the maintenance of privileges.  Rather than assigning a write privilege
  32  to each individual with write access, you can create a group with the members being the people
  33  needing write access, and assign the write privilege to that group.</p>
  34 <p>In this way as people come and go you can maintain the members of the group and it is easier to see
  35  who has the desired level of access.  If the needed level of access changes, you can change the grant
  36  to the individual group, rather than to each member of the group</p>
  37
  38 <h2>Privileges</h2>
  39 <p>The basic DAV permissions are as follows:</p>
  40 <p>read, write-properties, write-content, unlock, read-acl, read-current-user-privilege-set, write-acl, bind &amp; unbind</p>
  41
  42 <p>There are also a couple of useful aggregates of those, which are:</p>
  43 <ul>
  44 <li> write - aggregate of write-properties, write-content, bind &amp; unbind</li>
  45 <li> all   - aggregate of all permissions</li>
  46 </ul>
  47 <p>Since none of those covered publication of Free/Busy information, CalDAV introduced an additional <em>read-free-busy</em></p>
  48 <p>Unfortunately that didn't cover all of the possibilities of scheduling privileges, so the
  49  CalDAV Scheduling Extensions to WebDAV has added several further permissions:</p>
  50 <p>schedule-deliver-invite, schedule-deliver-reply, schedule-query-freebusy, schedule-send-invite,
  51  schedule-send-reply, schedule-send-freebusy
  52  </p>
  53 <p>Two more aggregate permissions are also added with this RFC:</p>
  54 <ul>
  55 <li> CALDAV:schedule-deliver - CALDAV:schedule-deliver-invite, CALDAV:schedule-deliver-reply and CALDAV:schedule-query-freebusy</li>
  56 <li> CALDAV:schedule-send - CALDAV:schedule-send-invite, CALDAV:schedule-send-reply and CALDAV:schedule-send-freebusy</li>
  57 </ul>
  58 <p>That's all way too complicated, even if it does need to be there under the covers.  Mostly you just need to know
  59  about <em>read</em>, <em>write</em> &amp; <em>free-busy</em></p>
  60
  61 <h2>Some Examples</h2>
  62
  63 <h3>Several people administer a set of resources</h3>
  64 <p>Suppose you have some resources, R1, R2 and R3 and you want to centralise the booking
  65 of the resources through an administrative assistant, A1.  When A1 is away you want to
  66 have a backup person, so you also want A2 to be able to do that.</p>
  67 <p>In a case like this you should create an intermediate group "G" and make each
  68  of the people you want to be able to administer those resources members of that
  69  group.</p>
  70 <p>Each of the resources should be set up to grant default privileges to everyone
  71  to see the full schedule (<em>read</em> privilege), and the resources should be
  72  set up to grant <em>write</em> (or possibly <em>all</em>) privileges to the group "G".</p>
  73 <p>In this case you might only set up a single principal for the resources, and have
  74  multiple calendars, one for each resource.</p>
  75 <pre>
  76 A1  ==>> is a member of    ==> G
  77 A2  ==>> is a member of    ==> G
  78 R1  ==>> grants write privilege to ==> G
  79 R2  ==>> grants write privilege to ==> G
  80 R3  ==>> grants write privilege to ==> G
  81 P1  is a different principal with no specifically granted privilege
  82 </pre>
  83 <p>P1 will be able to see all of the scheduled events for R1, R2 and R3, but will
  84 not be able to create, delete or modify them.  A1 and A2 will be able to see,
  85 create and modify all the events.</p>
  86
  87 <h4>An administrative assistant has full access to a managers calendar</h4>
  88 <p>In this case the manager will simply grant the desired specific privileges to their assistant.</p>
  89
  90 <h4>A team wish to see each others calendars</h4>
  91 <p>In this case you should create a group "G", which all team members are
  92 members of, and each team member will grant whatever privileges they wish to that group.</p>
  93 <pre>
  94 P1  ==>> is a member of  ==> G
  95 P1  ==>> grants read privilege to ==> G
  96 P2  ==>> is a member of  ==> G
  97 P2  ==>> grants read privilege to ==> G
  98 P3  ==>> is a member of  ==> G
  99 P3  ==>> grants write privilege to ==> G
 100 P4  ==>> is a member of  ==> G
 101 P4  ==>> grants read-free-busy privilege to ==> G
 102 </pre>
 103
 104 <h4>A team can modify each others calendars</h4>
 105 <p>Similar to above, you should create a group "G", which all team members are
 106 members of, and each team member will grant <em>write</em> privileges to that group.</p>
 107 <pre>
 108 P1  ==>> is a member of  ==> G
 109 P1  ==>> grants write privilege to ==> G
 110 P2  ==>> is a member of  ==> G
 111 P2  ==>> grants write privilege to ==> G
 112 P3  ==>> is a member of  ==> G
 113 P3  ==>> grants write privilege to ==> G
 114 P4  ==>> is a member of  ==> G
 115 P4  ==>> grants write privilege to ==> G
 116 </pre>
 117
 118 <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>
 119
 120 <h1>Configuring Calendar Clients for DAViCal</h1>
 121 <p>The <a href="clients.php">DAViCal client setup page on sourceforge</a> has information on how
 122 to configure Evolution, Mozilla Calendar (Sunbird &amp; Lightning) and Mulberry to use remotely hosted calendars.</p>
 123 <p>The administrative interface has no facility for viewing or modifying calendar data.</p>
 124
 125 <h1>Configuring DAViCal</h1>
 126 <p>If you can read this then things must be mostly working already.</p>
 127 <p>The <a href="installation.php">DAViCal installation page</a> on sourceforge has
 128 some further information on how to install and configure this application.</p>
 129
 130
 131 <?php
 132  include("inc/page-footer.php");