1.1 --- a/docs/wiki/Resources Fri May 13 01:10:08 2016 +0200
1.2 +++ b/docs/wiki/Resources Fri May 13 01:35:07 2016 +0200
1.3 @@ -413,6 +413,10 @@
1.4 EOF
1.5 }}}
1.6
1.7 +Note that this general quota applies to each individual identity and not
1.8 +collectively to all unspecified identities. To impose such a collective
1.9 +quota, a group may be defined for this purpose as described below.
1.10 +
1.11 When a user identity is not listed and no general quota is defined, that
1.12 particular user will be unable to reserve the resource unless defined as a
1.13 member of a group listed in the `limits` file, as described below.
1.14 @@ -420,9 +424,25 @@
1.15 ==== Sharing Quotas Across Users ====
1.16
1.17 When the use of resources is to be shared between users in such a way that
1.18 -groups of users will be sharing a single quota, the `groups` file in the
1.19 -quota directory must be defined, mapping each user identity to the group to
1.20 -which they will belong. For example:
1.21 +groups of users will be sharing a single quota, a `groups` file in a quota
1.22 +directory (or records in the `quota_groups` table) must be defined, mapping
1.23 +each user identity to the group to which they will belong.
1.24 +
1.25 +A tool is provided to define groups and is used as follows:
1.26 +
1.27 +{{{
1.28 +cat <<EOF | tools/set_quota_groups.py 'mailto:resource-car-cadillac@example.com'
1.29 +mailto:vincent.vole@example.com developers
1.30 +* others
1.31 +EOF
1.32 +}}}
1.33 +
1.34 +Here, otherwise unrecognised organisers are mapped to the `others` group.
1.35 +Thus, all scheduling performed by such organisers will be done in a common
1.36 +journal with this label.
1.37 +
1.38 +The process of determining where an organiser's usage of resources is
1.39 +recorded is illustrated by the following example:
1.40
1.41 {{{{#!table
1.42 '''Scheduling Data''' || '''Decision Process'''
1.43 @@ -674,3 +694,91 @@
1.44 }}}
1.45
1.46 }}}}
1.47 +
1.48 +==== Delegating Attendance ====
1.49 +
1.50 +A number of resources may be regarded as interchangeable and can therefore
1.51 +stand in for each other when they are unavailable. The iCalendar specification
1.52 +supports the notion of delegation: the recipient of an event invitation may
1.53 +delegate their attendance to other calendar user, informing that user and the
1.54 +event organiser of this decision.
1.55 +
1.56 +To define such delegation relationships, a quota is first selected as the
1.57 +repository of common scheduling information for a group of resources. Then,
1.58 +the members of the group are defined as delegates. This can be done using a
1.59 +tool provided for this purpose. For example:
1.60 +
1.61 +{{{
1.62 +cat <<EOF | tools/set_delegates.py 'cars'
1.63 +mailto:resource-car-cadillac@example.com
1.64 +mailto:resource-car-pontiac@example.com
1.65 +EOF
1.66 +}}}
1.67 +
1.68 +Here, two resources are defined that will delegate to each other if they
1.69 +cannot attend an event according to their own schedule.
1.70 +
1.71 +{{{{#!table
1.72 +'''Scheduling Functions''' || '''Decision Process'''
1.73 +==
1.74 +<style="vertical-align: top;">
1.75 +
1.76 +{{{
1.77 +schedule_for_delegate cars
1.78 +}}}
1.79 +
1.80 +||
1.81 +
1.82 +{{{#!graphviz
1.83 +//format=svg
1.84 +//transform=notugly
1.85 +digraph scheduling_decisions {
1.86 + node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"];
1.87 + edge [tooltip="Scheduling decisions"];
1.88 +
1.89 + subgraph {
1.90 + rank=same;
1.91 + mail_cadillac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-cadillac@example.com",shape=folder,style=filled,fillcolor=cyan];
1.92 + mail_pontiac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-pontiac@example.com",shape=folder,style=filled,fillcolor=cyan];
1.93 + cancel [label="Incoming cancellation",shape=folder,style=filled,fillcolor=cyan];
1.94 + }
1.95 +
1.96 + subgraph {
1.97 + rank=same;
1.98 + schedule_for_delegate [label="Can be scheduled or delegated?",shape=ellipse,style=filled,fillcolor=gold];
1.99 + quota_cars [label="Quota for cars",shape=folder];
1.100 + freebusy_cars_vole [label="...recording schedule for\nvincent.vole@example.com",shape=folder];
1.101 + }
1.102 +
1.103 + schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold];
1.104 +
1.105 + subgraph {
1.106 + rank=same;
1.107 + accept [label="Accept",shape=folder,style=filled,fillcolor=cyan];
1.108 + delegate [label="Delegate",shape=folder,style=filled,fillcolor=cyan];
1.109 + decline [label="Decline",shape=folder,style=filled,fillcolor=cyan];
1.110 + }
1.111 +
1.112 + add_to_quota [label="Add to quota",shape=ellipse,style=filled,fillcolor=darkorange];
1.113 + remove_from_quota [label="Remove from quota",shape=ellipse,style=filled,fillcolor=darkorange];
1.114 +
1.115 + mail_cadillac -> schedule_for_delegate;
1.116 + mail_pontiac -> schedule_for_delegate -> schedule -> accept;
1.117 + schedule_for_delegate -> delegate [style=dashed];
1.118 + schedule_for_delegate -> decline [style=dashed];
1.119 + schedule -> add_to_quota -> quota_cars -> freebusy_cars_vole;
1.120 + freebusy_cars_vole -> schedule_for_delegate;
1.121 +
1.122 + cancel -> remove_from_quota -> freebusy_cars_vole;
1.123 +}
1.124 +}}}
1.125 +
1.126 +}}}}
1.127 +
1.128 +Note that it is generally more useful to have delegation decisions made on the
1.129 +basis of many resources, which is what the journal entries for each quota
1.130 +provides, but also for many organisers attempting to reserve those resources.
1.131 +Although the journal for each quota may be divided up to administer quotas for
1.132 +multiple groups of organisers, for the purposes of delegation - deciding
1.133 +whether a resource is generally available, and deciding which other resource
1.134 +would be available instead - a single group of all organisers is more desirable.