mirror of
https://gitlab.com/davical-project/davical.git
synced 2026-01-27 00:33:34 +00:00
133 lines
6.9 KiB
PHP
133 lines
6.9 KiB
PHP
<?php
|
|
$title = "Administration";
|
|
include("inc/page-header.php");
|
|
?>
|
|
<h1>Administration Functions</h1>
|
|
<p>The administration of this application should be fairly simple. You can administer:</p>
|
|
<ul>
|
|
<li>Principals (Users, Resources or Groups)</li>
|
|
<li>Membership of groups</li>
|
|
<li>Privileges granted by a principal or collection to another principal</li>
|
|
|
|
</ul>
|
|
<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
|
|
(with the Lightning extension), Mulberry, Apple iCal, an iPhone or something else.</p>
|
|
|
|
<h2>Users, Resources and Groups</h2>
|
|
<p>These are the things which may have collections of calendar resources (i.e. calendars).</p>
|
|
<p>In the lists of principals you can click on any principal to see the full detail
|
|
for that record.</p>
|
|
<p>The primary differences between the types of principal are as follows:</p>
|
|
<ul>
|
|
<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>Groups provide an intermediate linking to minimise administration overhead. They might not have calendars, and they will not usually log on.</li>
|
|
</ul>
|
|
<p>These differences are more conceptual than actual, however: in the DAV specification they are really all 'principals' and all equal.</p>
|
|
|
|
<h2>Groups</h2>
|
|
<p>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.</p>
|
|
<p>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</p>
|
|
|
|
<h2>Privileges</h2>
|
|
<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 & unbind</p>
|
|
|
|
<p>There are also a couple of useful aggregates of those, which are:</p>
|
|
<ul>
|
|
<li> write - aggregate of write-properties, write-content, bind & unbind</li>
|
|
<li> all - aggregate of all permissions</li>
|
|
</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> & <em>free-busy</em></p>
|
|
|
|
<h2>Some Examples</h2>
|
|
|
|
<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
|
|
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>
|
|
<p>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.</p>
|
|
<p>Each of the resources should be set up to grant default privileges to everyone
|
|
to see the full schedule (<em>read</em> privilege), and the resources should be
|
|
set up to grant <em>write</em> (or possibly <em>all</em>) privileges to the group "G".</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>
|
|
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
|
|
</pre>
|
|
<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,
|
|
create and modify all the events.</p>
|
|
|
|
<h4>An administrative assistant has full access to a managers calendar</h4>
|
|
<p>In this case the manager will simply grant the desired specific privileges to their assistant.</p>
|
|
|
|
<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
|
|
members of, and each team member will grant whatever privileges they wish to that group.</p>
|
|
<pre>
|
|
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
|
|
</pre>
|
|
|
|
<h4>A team can modify each others calendars</h4>
|
|
<p>Similar to above, you should create a group "G", which all team members are
|
|
members of, and each team member will grant <em>write</em> privileges to that group.</p>
|
|
<pre>
|
|
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
|
|
</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>
|
|
<p>The <a href="clients.php">DAViCal client setup page on sourceforge</a> has information on how
|
|
to configure Evolution, Mozilla Calendar (Sunbird & Lightning) and Mulberry to use remotely hosted calendars.</p>
|
|
<p>The administrative interface has no facility for viewing or modifying calendar data.</p>
|
|
|
|
<h1>Configuring DAViCal</h1>
|
|
<p>If you can read this then things must be mostly working already.</p>
|
|
<p>The <a href="installation.php">DAViCal installation page</a> on sourceforge has
|
|
some further information on how to install and configure this application.</p>
|
|
|
|
|
|
<?php
|
|
include("inc/page-footer.php");
|