paul@1032 | 1 | = Resources = |
paul@1032 | 2 | |
paul@1032 | 3 | In imip-agent, resources are a special kind of user that act upon requests |
paul@1032 | 4 | to schedule events and that perform such scheduling autonomously, meaning |
paul@1032 | 5 | that no human intervention is necessary when such resources receive messages |
paul@1032 | 6 | containing invitations. |
paul@1032 | 7 | |
paul@1032 | 8 | By default, the [[../AgentPrograms|agent program]] responsible for resources |
paul@1032 | 9 | merely attempts to fit a received event into the resource's schedule. However, |
paul@1032 | 10 | in some organisations and environments, it is likely to be the case that other |
paul@1032 | 11 | policies are needed to ensure that a resource is not misused, overused or made |
paul@1032 | 12 | unnecessarily unavailable. |
paul@1032 | 13 | |
paul@1032 | 14 | The [[../Preferences|preferences]] provide a way of controlling the behaviour |
paul@1032 | 15 | of resources, just as with any other kind of user, but certain preferences |
paul@1032 | 16 | are central to the configuration of resources. |
paul@1032 | 17 | |
paul@1032 | 18 | <<TableOfContents(2,4)>> |
paul@1032 | 19 | |
paul@1032 | 20 | == Scheduling Functions == |
paul@1032 | 21 | |
paul@1032 | 22 | The [[../Preferences#scheduling_function|scheduling_function]] setting |
paul@1032 | 23 | indicates the behaviour of a resource when a valid request to schedule an |
paul@1032 | 24 | event has been received. By default, a value equivalent to the following is |
paul@1032 | 25 | employed: |
paul@1032 | 26 | |
paul@1037 | 27 | {{{{#!table |
paul@1037 | 28 | '''Scheduling Functions''' || '''Decision Process''' |
paul@1037 | 29 | == |
paul@1037 | 30 | <style="vertical-align: top;"> |
paul@1037 | 31 | |
paul@1032 | 32 | {{{ |
paul@1032 | 33 | schedule_in_freebusy |
paul@1032 | 34 | }}} |
paul@1032 | 35 | |
paul@1037 | 36 | || |
paul@1037 | 37 | |
paul@1037 | 38 | {{{#!graphviz |
paul@1037 | 39 | //format=svg |
paul@1037 | 40 | //transform=notugly |
paul@1037 | 41 | digraph scheduling_decisions { |
paul@1037 | 42 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1037 | 43 | edge [tooltip="Scheduling decisions"]; |
paul@1037 | 44 | |
paul@1037 | 45 | mail [label="Incoming mail",shape=folder,style=filled,fillcolor=cyan]; |
paul@1037 | 46 | |
paul@1037 | 47 | subgraph { |
paul@1037 | 48 | rank=same; |
paul@1037 | 49 | schedule_in_freebusy [label="Can schedule in free/busy?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 50 | freebusy [label="Free/busy",shape=folder]; |
paul@1037 | 51 | } |
paul@1037 | 52 | |
paul@1037 | 53 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 54 | |
paul@1039 | 55 | subgraph { |
paul@1039 | 56 | rank=same; |
paul@1039 | 57 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 58 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 59 | } |
paul@1037 | 60 | |
paul@1037 | 61 | mail -> schedule_in_freebusy -> schedule -> accept; |
paul@1037 | 62 | schedule_in_freebusy -> decline [style=dashed]; |
paul@1037 | 63 | freebusy -> schedule_in_freebusy; |
paul@1037 | 64 | } |
paul@1037 | 65 | }}} |
paul@1037 | 66 | |
paul@1037 | 67 | }}}} |
paul@1037 | 68 | |
paul@1032 | 69 | As described above, this merely attempts to schedule an event in the free |
paul@1032 | 70 | periods of the resource's schedule. However, no attempt is made to reject the |
paul@1032 | 71 | booking of the resource according to the identity of the organiser. |
paul@1032 | 72 | |
paul@1183 | 73 | === Concurrent Reservations === |
paul@1183 | 74 | |
paul@1183 | 75 | The `schedule_in_freebusy` function causes a resource to attempt to schedule |
paul@1183 | 76 | an event, and by default it rejects requests that involve periods for which |
paul@1183 | 77 | the resource is otherwise committed. However, a resource can be allowed to |
paul@1183 | 78 | attend (or commit to) multiple concurrent events. |
paul@1183 | 79 | |
paul@1183 | 80 | By indicating a value as an argument to the function, a kind of capacity or |
paul@1183 | 81 | commitment level can be assigned to a resource. For example: |
paul@1183 | 82 | |
paul@1183 | 83 | {{{ |
paul@1183 | 84 | schedule_in_freebusy 5 |
paul@1183 | 85 | }}} |
paul@1183 | 86 | |
paul@1183 | 87 | This example indicates that a resource can support five different events |
paul@1183 | 88 | occupying the same point in time. Applications of such concurrent reservations |
paul@1183 | 89 | include things like rooms or resources that can be shared and which have a |
paul@1183 | 90 | notion of a capacity that is not immediately exhausted as soon as one event |
paul@1183 | 91 | seeks to reserve such a room or resource. |
paul@1183 | 92 | |
paul@1032 | 93 | === Identity Controls === |
paul@1032 | 94 | |
paul@1032 | 95 | Although identity controls may be implemented in the e-mail system, |
paul@1032 | 96 | effectively preventing the messages from addresses other than those within |
paul@1032 | 97 | an organisation (for example) from being delivered to the resource, it is |
paul@1032 | 98 | possible to use scheduling functions to implement such controls instead. |
paul@1032 | 99 | |
paul@1032 | 100 | ==== Same Domain Membership ==== |
paul@1032 | 101 | |
paul@1032 | 102 | For instance, the following combines the default free/busy check with a |
paul@1032 | 103 | test that the organiser belongs to the same Internet mail domain (by using |
paul@1032 | 104 | the organiser's address): |
paul@1032 | 105 | |
paul@1037 | 106 | {{{{#!table |
paul@1037 | 107 | '''Scheduling Functions''' || '''Decision Process''' |
paul@1037 | 108 | == |
paul@1037 | 109 | <style="vertical-align: top;"> |
paul@1037 | 110 | |
paul@1032 | 111 | {{{ |
paul@1032 | 112 | schedule_in_freebusy |
paul@1032 | 113 | same_domain_only |
paul@1032 | 114 | }}} |
paul@1032 | 115 | |
paul@1037 | 116 | || |
paul@1037 | 117 | |
paul@1037 | 118 | {{{#!graphviz |
paul@1037 | 119 | //format=svg |
paul@1037 | 120 | //transform=notugly |
paul@1037 | 121 | digraph scheduling_decisions { |
paul@1037 | 122 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1037 | 123 | edge [tooltip="Scheduling decisions"]; |
paul@1037 | 124 | |
paul@1037 | 125 | mail [label="Incoming mail",shape=folder,style=filled,fillcolor=cyan]; |
paul@1037 | 126 | |
paul@1037 | 127 | subgraph { |
paul@1037 | 128 | rank=same; |
paul@1037 | 129 | schedule_in_freebusy [label="Can schedule in free/busy?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 130 | freebusy [label="Free/busy",shape=folder]; |
paul@1037 | 131 | } |
paul@1037 | 132 | |
paul@1037 | 133 | same_domain_only [label="Organiser has resource domain?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 134 | |
paul@1037 | 135 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 136 | |
paul@1039 | 137 | subgraph { |
paul@1039 | 138 | rank=same; |
paul@1039 | 139 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 140 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 141 | } |
paul@1037 | 142 | |
paul@1037 | 143 | mail -> schedule_in_freebusy -> same_domain_only -> schedule -> accept; |
paul@1037 | 144 | schedule_in_freebusy -> decline [style=dashed]; |
paul@1037 | 145 | same_domain_only -> decline [style=dashed]; |
paul@1037 | 146 | freebusy -> schedule_in_freebusy; |
paul@1037 | 147 | } |
paul@1037 | 148 | }}} |
paul@1037 | 149 | |
paul@1037 | 150 | }}}} |
paul@1037 | 151 | |
paul@1032 | 152 | Note that if the first function is omitted, no check against the resource's |
paul@1032 | 153 | schedule will occur, so it is necessary to mention any such function in the |
paul@1032 | 154 | list. |
paul@1032 | 155 | |
paul@1032 | 156 | ==== Access Control Lists ==== |
paul@1032 | 157 | |
paul@1032 | 158 | A simple domain-related test may not be sufficient to control access to a |
paul@1032 | 159 | resource. Thus, another function is provided to exercise a finer degree of |
paul@1032 | 160 | control over event participants. For example: |
paul@1032 | 161 | |
paul@1037 | 162 | {{{{#!table |
paul@1037 | 163 | '''Scheduling Functions and Data''' || '''Decision Process''' |
paul@1037 | 164 | == |
paul@1037 | 165 | <style="vertical-align: top;"> |
paul@1037 | 166 | |
paul@1032 | 167 | {{{ |
paul@1032 | 168 | schedule_in_freebusy |
paul@1032 | 169 | access_control_list |
paul@1032 | 170 | }}} |
paul@1032 | 171 | |
paul@1037 | 172 | Access control list: |
paul@1037 | 173 | |
paul@1037 | 174 | {{{ |
paul@1037 | 175 | accept |
paul@1037 | 176 | }}} |
paul@1037 | 177 | |
paul@1037 | 178 | || |
paul@1037 | 179 | |
paul@1037 | 180 | {{{#!graphviz |
paul@1037 | 181 | //format=svg |
paul@1037 | 182 | //transform=notugly |
paul@1037 | 183 | digraph scheduling_decisions { |
paul@1037 | 184 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1037 | 185 | edge [tooltip="Scheduling decisions"]; |
paul@1037 | 186 | |
paul@1037 | 187 | mail [label="Incoming mail",shape=folder,style=filled,fillcolor=cyan]; |
paul@1037 | 188 | |
paul@1037 | 189 | subgraph { |
paul@1037 | 190 | rank=same; |
paul@1037 | 191 | schedule_in_freebusy [label="Can schedule in free/busy?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 192 | freebusy [label="Free/busy",shape=folder]; |
paul@1037 | 193 | } |
paul@1037 | 194 | |
paul@1037 | 195 | subgraph { |
paul@1037 | 196 | rank=same; |
paul@1037 | 197 | access_control_list [label="Access control list permits booking?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 198 | acl [label="acl setting",shape=folder]; |
paul@1037 | 199 | } |
paul@1037 | 200 | |
paul@1037 | 201 | accept_default [label="Accept invitation by default",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 202 | end_acl [label="end",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 203 | |
paul@1037 | 204 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 205 | |
paul@1039 | 206 | subgraph { |
paul@1039 | 207 | rank=same; |
paul@1039 | 208 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 209 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 210 | } |
paul@1037 | 211 | |
paul@1037 | 212 | mail -> schedule_in_freebusy -> access_control_list -> accept_default -> end_acl -> schedule -> accept; |
paul@1037 | 213 | end_acl -> decline [style=dashed]; |
paul@1037 | 214 | schedule_in_freebusy -> decline [style=dashed]; |
paul@1037 | 215 | freebusy -> schedule_in_freebusy; |
paul@1037 | 216 | acl -> access_control_list; |
paul@1037 | 217 | } |
paul@1037 | 218 | }}} |
paul@1037 | 219 | |
paul@1037 | 220 | }}}} |
paul@1037 | 221 | |
paul@1037 | 222 | To accompany the scheduling functions, the [[../Preferences#acl|acl]] setting |
paul@1037 | 223 | in the resource's preferences must be set, or if a separate file is more |
paul@1037 | 224 | appropriate, its full path may be given as an argument to `access_control_list`: |
paul@1032 | 225 | |
paul@1032 | 226 | {{{ |
paul@1032 | 227 | schedule_in_freebusy |
paul@1032 | 228 | access_control_list /etc/imip-agent/resources.acl |
paul@1032 | 229 | }}} |
paul@1032 | 230 | |
paul@1032 | 231 | Within the file provided by the setting or separate file, a list of rules |
paul@1037 | 232 | must describe the handling procedure for an event. For example, the following |
paul@1037 | 233 | was given in the above example: |
paul@1032 | 234 | |
paul@1032 | 235 | {{{ |
paul@1032 | 236 | accept |
paul@1032 | 237 | }}} |
paul@1032 | 238 | |
paul@1032 | 239 | This will merely accept all invitations, anyway. However, it may be |
paul@1032 | 240 | appropriate to prevent certain users from using resources. For example: |
paul@1032 | 241 | |
paul@1037 | 242 | {{{{#!table |
paul@1037 | 243 | '''Scheduling Functions and Data''' || '''Decision Process''' |
paul@1037 | 244 | == |
paul@1037 | 245 | <style="vertical-align: top;"> |
paul@1037 | 246 | |
paul@1037 | 247 | {{{ |
paul@1037 | 248 | schedule_in_freebusy |
paul@1037 | 249 | access_control_list |
paul@1037 | 250 | }}} |
paul@1037 | 251 | |
paul@1037 | 252 | Access control list: |
paul@1037 | 253 | |
paul@1032 | 254 | {{{ |
paul@1032 | 255 | accept |
paul@1032 | 256 | decline attendee simon.skunk@example.com |
paul@1032 | 257 | }}} |
paul@1032 | 258 | |
paul@1037 | 259 | || |
paul@1037 | 260 | |
paul@1037 | 261 | {{{#!graphviz |
paul@1037 | 262 | //format=svg |
paul@1037 | 263 | //transform=notugly |
paul@1037 | 264 | digraph scheduling_decisions { |
paul@1037 | 265 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1037 | 266 | edge [tooltip="Scheduling decisions"]; |
paul@1037 | 267 | |
paul@1037 | 268 | mail [label="Incoming mail",shape=folder,style=filled,fillcolor=cyan]; |
paul@1037 | 269 | |
paul@1037 | 270 | subgraph { |
paul@1037 | 271 | rank=same; |
paul@1037 | 272 | schedule_in_freebusy [label="Can schedule in free/busy?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 273 | freebusy [label="Free/busy",shape=folder]; |
paul@1037 | 274 | } |
paul@1037 | 275 | |
paul@1037 | 276 | subgraph { |
paul@1037 | 277 | rank=same; |
paul@1037 | 278 | access_control_list [label="Access control list permits booking?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 279 | acl [label="acl setting",shape=folder]; |
paul@1037 | 280 | } |
paul@1037 | 281 | |
paul@1037 | 282 | accept_default [label="Accept invitation by default",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 283 | decline_attendee [label="Is attendee simon.skunk@example.com?",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 284 | end_acl [label="end",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 285 | |
paul@1037 | 286 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 287 | |
paul@1039 | 288 | subgraph { |
paul@1039 | 289 | rank=same; |
paul@1039 | 290 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 291 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 292 | } |
paul@1037 | 293 | |
paul@1037 | 294 | mail -> schedule_in_freebusy -> access_control_list -> accept_default -> decline_attendee -> end_acl -> schedule -> accept; |
paul@1037 | 295 | end_acl -> decline [style=dashed]; |
paul@1037 | 296 | schedule_in_freebusy -> decline [style=dashed]; |
paul@1037 | 297 | freebusy -> schedule_in_freebusy; |
paul@1037 | 298 | acl -> access_control_list; |
paul@1037 | 299 | } |
paul@1037 | 300 | }}} |
paul@1037 | 301 | |
paul@1037 | 302 | }}}} |
paul@1037 | 303 | |
paul@1032 | 304 | This example indicates that by default, invitations will be accepted, but if |
paul@1032 | 305 | one of the attendees of an event is `simon.skunk@example.com`, the invitation |
paul@1032 | 306 | will be declined. However, it may be the case that this rule should be |
paul@1032 | 307 | overridden under certain circumstances. For example: |
paul@1032 | 308 | |
paul@1037 | 309 | {{{{#!table |
paul@1037 | 310 | '''Scheduling Functions and Data''' || '''Decision Process''' |
paul@1037 | 311 | == |
paul@1037 | 312 | <style="vertical-align: top;"> |
paul@1037 | 313 | |
paul@1037 | 314 | {{{ |
paul@1037 | 315 | schedule_in_freebusy |
paul@1037 | 316 | access_control_list |
paul@1037 | 317 | }}} |
paul@1037 | 318 | |
paul@1037 | 319 | Access control list: |
paul@1037 | 320 | |
paul@1032 | 321 | {{{ |
paul@1032 | 322 | accept |
paul@1032 | 323 | decline attendee simon.skunk@example.com |
paul@1032 | 324 | accept organiser paul.boddie@example.com |
paul@1032 | 325 | }}} |
paul@1032 | 326 | |
paul@1037 | 327 | || |
paul@1037 | 328 | |
paul@1037 | 329 | {{{#!graphviz |
paul@1037 | 330 | //format=svg |
paul@1037 | 331 | //transform=notugly |
paul@1037 | 332 | digraph scheduling_decisions { |
paul@1037 | 333 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1037 | 334 | edge [tooltip="Scheduling decisions"]; |
paul@1037 | 335 | |
paul@1037 | 336 | mail [label="Incoming mail",shape=folder,style=filled,fillcolor=cyan]; |
paul@1037 | 337 | |
paul@1037 | 338 | subgraph { |
paul@1037 | 339 | rank=same; |
paul@1037 | 340 | schedule_in_freebusy [label="Can schedule in free/busy?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 341 | freebusy [label="Free/busy",shape=folder]; |
paul@1037 | 342 | } |
paul@1037 | 343 | |
paul@1037 | 344 | subgraph { |
paul@1037 | 345 | rank=same; |
paul@1037 | 346 | access_control_list [label="Access control list permits booking?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1037 | 347 | acl [label="acl setting",shape=folder]; |
paul@1037 | 348 | } |
paul@1037 | 349 | |
paul@1037 | 350 | accept_default [label="Accept invitation by default",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 351 | decline_attendee [label="Is attendee simon.skunk@example.com?",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 352 | accept_organiser [label="Is organiser paul.boddie@example.com?",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 353 | end_acl [label="end",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1037 | 354 | |
paul@1037 | 355 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 356 | |
paul@1039 | 357 | subgraph { |
paul@1039 | 358 | rank=same; |
paul@1039 | 359 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 360 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 361 | } |
paul@1037 | 362 | |
paul@1037 | 363 | mail -> schedule_in_freebusy -> access_control_list -> accept_default -> decline_attendee -> accept_organiser -> end_acl -> schedule -> accept; |
paul@1037 | 364 | end_acl -> decline [style=dashed]; |
paul@1037 | 365 | schedule_in_freebusy -> decline [style=dashed]; |
paul@1037 | 366 | freebusy -> schedule_in_freebusy; |
paul@1037 | 367 | acl -> access_control_list; |
paul@1037 | 368 | } |
paul@1037 | 369 | }}} |
paul@1037 | 370 | |
paul@1037 | 371 | }}}} |
paul@1037 | 372 | |
paul@1032 | 373 | Here, the stated organiser may still arrange a booking of the resource where |
paul@1032 | 374 | the previously-mentioned attendee is involved. |
paul@1039 | 375 | |
paul@1039 | 376 | === Quota Controls === |
paul@1039 | 377 | |
paul@1039 | 378 | In contrast to each user's stored information which consolidates information |
paul@1039 | 379 | related to that user's own schedule, the quota system consolidates information |
paul@1039 | 380 | related to the schedules of one or more resources, thus enabling observations |
paul@1039 | 381 | to be made about their collective usage. |
paul@1039 | 382 | |
paul@1039 | 383 | First, consider a resource such as a car where an organiser of an event may be |
paul@1039 | 384 | booking the car for travel purposes. A quota prevents the organiser from |
paul@1039 | 385 | booking the resource too much and denying other users access to it. |
paul@1039 | 386 | |
paul@1039 | 387 | Now consider a number of separate car resources. An organiser might attempt to |
paul@1039 | 388 | get around any individual resource quota by booking a number of different cars. |
paul@1167 | 389 | By grouping the resources together, the organiser will exhaust any quota set on |
paul@1167 | 390 | the group of resources as they try and make reservations for the different |
paul@1167 | 391 | members of the quota group. |
paul@1039 | 392 | |
paul@1039 | 393 | ==== Initialising Quotas ==== |
paul@1039 | 394 | |
paul@1165 | 395 | Within the journal storage area, a quota may be initialised with limits |
paul@1165 | 396 | indicating the amount of time that can be occupied by the cumulative total of |
paul@1165 | 397 | all events scheduled by an individual user or a group of which they are a |
paul@1165 | 398 | member. |
paul@1165 | 399 | |
paul@1165 | 400 | Such limits may be set directly using the `limits` file in a quota directory |
paul@1165 | 401 | (described in the [[../FilesystemUsage|filesystem guide]]) or in the |
paul@1165 | 402 | `quota_limits` table (described in the [[../DatabaseStore|database guide]]), |
paul@1165 | 403 | but a tool is also provided to set such limits. For example: |
paul@1039 | 404 | |
paul@1039 | 405 | {{{ |
paul@1178 | 406 | cat <<EOF | set_quota_limits.py 'mailto:resource-car-cadillac@example.com' |
paul@1178 | 407 | mailto:vincent.vole@example.com PT10H |
paul@1178 | 408 | EOF |
paul@1039 | 409 | }}} |
paul@1039 | 410 | |
paul@1178 | 411 | {{{#!wiki tip |
paul@1178 | 412 | In the above example, shell syntax is used to indicate a |
paul@1178 | 413 | [[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04|here document]] |
paul@1178 | 414 | providing a kind of "inline" file that is terminated by the final `EOF`. |
paul@1178 | 415 | The contents of this file are piped to the tool with a single argument given |
paul@1178 | 416 | indicating the quota involved. |
paul@1178 | 417 | |
paul@1178 | 418 | You could also just invoke the tool and then enter the limit descriptions, |
paul@1178 | 419 | ending the input with Ctrl-D or equivalent end-of-file keystroke, or save |
paul@1178 | 420 | the descriptions in a file and then use input redirection with the filename. |
paul@1178 | 421 | }}} |
paul@1178 | 422 | |
paul@1178 | 423 | The above example indicates that the given user may only reserve 10 hours |
paul@1178 | 424 | of events or less time within the given quota (corresponding to a specific |
paul@1178 | 425 | resource in the above example). Attempts to schedule more time will be |
paul@1178 | 426 | declined. |
paul@1039 | 427 | |
paul@1039 | 428 | To impose a general quota, the special `*` identity can be used: |
paul@1039 | 429 | |
paul@1039 | 430 | {{{ |
paul@1178 | 431 | cat <<EOF | set_quota_limits.py 'mailto:resource-car-cadillac@example.com' |
paul@1178 | 432 | * PT10H |
paul@1178 | 433 | EOF |
paul@1039 | 434 | }}} |
paul@1039 | 435 | |
paul@1180 | 436 | Note that this general quota applies to each individual identity and not |
paul@1180 | 437 | collectively to all unspecified identities. To impose such a collective |
paul@1180 | 438 | quota, a group may be defined for this purpose as described below. |
paul@1180 | 439 | |
paul@1039 | 440 | When a user identity is not listed and no general quota is defined, that |
paul@1039 | 441 | particular user will be unable to reserve the resource unless defined as a |
paul@1039 | 442 | member of a group listed in the `limits` file, as described below. |
paul@1039 | 443 | |
paul@1039 | 444 | ==== Sharing Quotas Across Users ==== |
paul@1039 | 445 | |
paul@1039 | 446 | When the use of resources is to be shared between users in such a way that |
paul@1180 | 447 | groups of users will be sharing a single quota, a `groups` file in a quota |
paul@1180 | 448 | directory (or records in the `quota_groups` table) must be defined, mapping |
paul@1180 | 449 | each user identity to the group to which they will belong. |
paul@1180 | 450 | |
paul@1180 | 451 | A tool is provided to define groups and is used as follows: |
paul@1180 | 452 | |
paul@1180 | 453 | {{{ |
paul@1180 | 454 | cat <<EOF | tools/set_quota_groups.py 'mailto:resource-car-cadillac@example.com' |
paul@1180 | 455 | mailto:vincent.vole@example.com developers |
paul@1180 | 456 | * others |
paul@1180 | 457 | EOF |
paul@1180 | 458 | }}} |
paul@1180 | 459 | |
paul@1180 | 460 | Here, otherwise unrecognised organisers are mapped to the `others` group. |
paul@1180 | 461 | Thus, all scheduling performed by such organisers will be done in a common |
paul@1180 | 462 | journal with this label. |
paul@1180 | 463 | |
paul@1180 | 464 | The process of determining where an organiser's usage of resources is |
paul@1180 | 465 | recorded is illustrated by the following example: |
paul@1039 | 466 | |
paul@1167 | 467 | {{{{#!table |
paul@1167 | 468 | '''Scheduling Data''' || '''Decision Process''' |
paul@1167 | 469 | == |
paul@1167 | 470 | <style="vertical-align: top;"> |
paul@1167 | 471 | The groups are defined as follows in the `groups` file: |
paul@1167 | 472 | |
paul@1039 | 473 | {{{ |
paul@1039 | 474 | mailto:vincent.vole@example.com developers |
paul@1039 | 475 | mailto:harvey.horse@example.com developers |
paul@1039 | 476 | mailto:paul.boddie@example.com developers |
paul@1039 | 477 | mailto:simon.skunk@example.com testers |
paul@1039 | 478 | }}} |
paul@1039 | 479 | |
paul@1039 | 480 | The group identity can then be employed in the `limits` file: |
paul@1039 | 481 | |
paul@1039 | 482 | {{{ |
paul@1039 | 483 | developers PT10H |
paul@1039 | 484 | testers PT20H |
paul@1039 | 485 | }}} |
paul@1039 | 486 | |
paul@1167 | 487 | || |
paul@1167 | 488 | |
paul@1167 | 489 | {{{#!graphviz |
paul@1167 | 490 | //format=svg |
paul@1167 | 491 | //transform=notugly |
paul@1167 | 492 | digraph quota_users { |
paul@1167 | 493 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Quota users"]; |
paul@1167 | 494 | edge [tooltip="Quota users"]; |
paul@1167 | 495 | |
paul@1167 | 496 | subgraph { |
paul@1167 | 497 | rank=same; |
paul@1167 | 498 | user1 [label="User is vincent.vole@example.com"]; |
paul@1167 | 499 | user2 [label="User is oliver.otter@example.com"]; |
paul@1167 | 500 | } |
paul@1167 | 501 | |
paul@1167 | 502 | havegroup [label="Have group for quota?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1167 | 503 | haveuser [label="Have group for user in quota?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1167 | 504 | |
paul@1167 | 505 | group1 [label="User is vincent.vole@example.com\nGroup is developers"]; |
paul@1167 | 506 | group2 [label="User is oliver.otter@example.com"]; |
paul@1167 | 507 | |
paul@1167 | 508 | checkuser1 [label="Have limit for group?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1167 | 509 | checkgeneral1 [label="Have general limit?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1167 | 510 | |
paul@1167 | 511 | checkuser2 [label="Have limit for user?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1167 | 512 | checkgeneral2 [label="Have general limit?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1167 | 513 | |
paul@1167 | 514 | accept [label="Quota",shape=folder,style=filled,fillcolor=cyan]; |
paul@1167 | 515 | decline [label="No quota",shape=folder,style=filled,fillcolor=cyan]; |
paul@1167 | 516 | |
paul@1167 | 517 | user1 -> havegroup -> haveuser -> group1 -> checkuser1 -> checkgeneral1 -> accept; |
paul@1167 | 518 | user2 -> havegroup -> haveuser -> group2 -> checkuser2 -> checkgeneral2 -> decline [style=dashed]; |
paul@1167 | 519 | } |
paul@1167 | 520 | }}} |
paul@1167 | 521 | }}}} |
paul@1167 | 522 | |
paul@1167 | 523 | Where individuals are not assigned to groups, any individual limit will apply |
paul@1167 | 524 | to them; otherwise, the general quota applies. Where individuals are assigned |
paul@1167 | 525 | to groups, any group limit will apply; otherwise, the general quota applies. |
paul@1039 | 526 | |
paul@1039 | 527 | ==== Individual Resource Quotas ==== |
paul@1039 | 528 | |
paul@1039 | 529 | The trivial case of applying quotas is to give a resource its own quota. This |
paul@1039 | 530 | is achieved by not specifying any arguments to the `check_quota` scheduling |
paul@1058 | 531 | function or to the `add_to_quota` and `remove_from_quota` functions. |
paul@1058 | 532 | |
paul@1058 | 533 | {{{{#!table |
paul@1058 | 534 | '''Scheduling Functions''' || '''Decision Process''' |
paul@1058 | 535 | == |
paul@1058 | 536 | <style="vertical-align: top;"> |
paul@1058 | 537 | |
paul@1058 | 538 | {{{ |
paul@1058 | 539 | check_quota |
paul@1058 | 540 | }}} |
paul@1058 | 541 | |
paul@1058 | 542 | || |
paul@1058 | 543 | |
paul@1058 | 544 | {{{#!graphviz |
paul@1058 | 545 | //format=svg |
paul@1058 | 546 | //transform=notugly |
paul@1058 | 547 | digraph scheduling_decisions { |
paul@1058 | 548 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1058 | 549 | edge [tooltip="Scheduling decisions"]; |
paul@1058 | 550 | |
paul@1058 | 551 | subgraph { |
paul@1058 | 552 | rank=same; |
paul@1058 | 553 | mail [label="Incoming mail\nfrom vincent.vole@example.com",shape=folder,style=filled,fillcolor=cyan]; |
paul@1058 | 554 | cancel [label="Incoming cancellation",shape=folder,style=filled,fillcolor=cyan]; |
paul@1058 | 555 | } |
paul@1058 | 556 | |
paul@1058 | 557 | subgraph { |
paul@1058 | 558 | rank=same; |
paul@1058 | 559 | check_quota [label="Is allowed by quota?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1058 | 560 | quota [label="Quota for resource",shape=folder]; |
paul@1058 | 561 | quota_for_vole [label="...applying to\nvincent.vole@example.com",shape=folder]; |
paul@1058 | 562 | } |
paul@1058 | 563 | |
paul@1058 | 564 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1058 | 565 | |
paul@1058 | 566 | subgraph { |
paul@1058 | 567 | rank=same; |
paul@1058 | 568 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1058 | 569 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1058 | 570 | } |
paul@1058 | 571 | |
paul@1058 | 572 | add_to_quota [label="Add to quota",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1058 | 573 | remove_from_quota [label="Remove from quota",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1058 | 574 | |
paul@1058 | 575 | mail -> check_quota -> schedule -> accept; |
paul@1058 | 576 | check_quota -> decline [style=dashed]; |
paul@1058 | 577 | schedule -> add_to_quota -> quota; |
paul@1058 | 578 | quota -> quota_for_vole -> check_quota; |
paul@1058 | 579 | |
paul@1058 | 580 | cancel -> remove_from_quota -> quota; |
paul@1058 | 581 | } |
paul@1058 | 582 | }}} |
paul@1058 | 583 | |
paul@1058 | 584 | }}}} |
paul@1039 | 585 | |
paul@1039 | 586 | ==== Common Resource Quotas ==== |
paul@1039 | 587 | |
paul@1039 | 588 | By indicating an argument to the different functions, a common quota can be |
paul@1039 | 589 | employed. In the following example, both resources would employ the given |
paul@1039 | 590 | function invocations to pool their knowledge about their schedules. |
paul@1039 | 591 | |
paul@1039 | 592 | {{{{#!table |
paul@1058 | 593 | '''Scheduling Functions''' || '''Decision Process''' |
paul@1039 | 594 | == |
paul@1039 | 595 | <style="vertical-align: top;"> |
paul@1039 | 596 | |
paul@1039 | 597 | {{{ |
paul@1039 | 598 | check_quota cars |
paul@1039 | 599 | }}} |
paul@1039 | 600 | |
paul@1039 | 601 | || |
paul@1039 | 602 | |
paul@1039 | 603 | {{{#!graphviz |
paul@1039 | 604 | //format=svg |
paul@1039 | 605 | //transform=notugly |
paul@1039 | 606 | digraph scheduling_decisions { |
paul@1039 | 607 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1039 | 608 | edge [tooltip="Scheduling decisions"]; |
paul@1039 | 609 | |
paul@1039 | 610 | subgraph { |
paul@1039 | 611 | rank=same; |
paul@1039 | 612 | mail_cadillac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-cadillac@example.com",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 613 | mail_pontiac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-pontiac@example.com",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 614 | cancel [label="Incoming cancellation",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 615 | } |
paul@1039 | 616 | |
paul@1039 | 617 | subgraph { |
paul@1039 | 618 | rank=same; |
paul@1039 | 619 | check_quota [label="Is allowed by quota?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 620 | quota_cars [label="Quota for cars",shape=folder]; |
paul@1039 | 621 | quota_cars_vole [label="...applying to\nvincent.vole@example.com",shape=folder]; |
paul@1039 | 622 | } |
paul@1039 | 623 | |
paul@1039 | 624 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 625 | |
paul@1039 | 626 | subgraph { |
paul@1039 | 627 | rank=same; |
paul@1039 | 628 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 629 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 630 | } |
paul@1039 | 631 | |
paul@1039 | 632 | add_to_quota [label="Add to quota",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1039 | 633 | remove_from_quota [label="Remove from quota",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1039 | 634 | |
paul@1039 | 635 | mail_cadillac -> check_quota; |
paul@1039 | 636 | mail_pontiac -> check_quota -> schedule -> accept; |
paul@1039 | 637 | check_quota -> decline [style=dashed]; |
paul@1039 | 638 | schedule -> add_to_quota -> quota_cars; |
paul@1039 | 639 | quota_cars -> quota_cars_vole -> check_quota; |
paul@1039 | 640 | |
paul@1039 | 641 | cancel -> remove_from_quota -> quota_cars; |
paul@1039 | 642 | } |
paul@1039 | 643 | }}} |
paul@1039 | 644 | |
paul@1039 | 645 | }}}} |
paul@1039 | 646 | |
paul@1039 | 647 | ==== Collective Scheduling ==== |
paul@1039 | 648 | |
paul@1039 | 649 | Consider two separate resources: both may be reserved at the same time by the |
paul@1039 | 650 | same organiser; neither resource would normally decline the reservation on the |
paul@1039 | 651 | basis of schedule availability, should the period concerned be free. However, |
paul@1039 | 652 | it may be undesirable for one organiser to occupy both resources at the same |
paul@1039 | 653 | time. |
paul@1039 | 654 | |
paul@1039 | 655 | Consequently, a mechanism is required to pool the resource schedules in such a |
paul@1039 | 656 | way that any reservation performed for one resource at a given point in time |
paul@1039 | 657 | prohibits another reservation performed for a related resource at the same |
paul@1039 | 658 | point in time by the same user. |
paul@1039 | 659 | |
paul@1039 | 660 | The free/busy records held for a given quota group permit such collective |
paul@1039 | 661 | scheduling decisions and are employed as follows: |
paul@1039 | 662 | |
paul@1039 | 663 | {{{{#!table |
paul@1058 | 664 | '''Scheduling Functions''' || '''Decision Process''' |
paul@1039 | 665 | == |
paul@1039 | 666 | <style="vertical-align: top;"> |
paul@1039 | 667 | |
paul@1039 | 668 | {{{ |
paul@1164 | 669 | schedule_across_quota cars |
paul@1039 | 670 | }}} |
paul@1039 | 671 | |
paul@1039 | 672 | || |
paul@1039 | 673 | |
paul@1039 | 674 | {{{#!graphviz |
paul@1039 | 675 | //format=svg |
paul@1039 | 676 | //transform=notugly |
paul@1039 | 677 | digraph scheduling_decisions { |
paul@1039 | 678 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1039 | 679 | edge [tooltip="Scheduling decisions"]; |
paul@1039 | 680 | |
paul@1039 | 681 | subgraph { |
paul@1039 | 682 | rank=same; |
paul@1039 | 683 | mail_cadillac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-cadillac@example.com",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 684 | mail_pontiac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-pontiac@example.com",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 685 | cancel [label="Incoming cancellation",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 686 | } |
paul@1039 | 687 | |
paul@1039 | 688 | subgraph { |
paul@1039 | 689 | rank=same; |
paul@1039 | 690 | schedule_across_quota [label="Can be scheduled within the quota?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 691 | quota_cars [label="Quota for cars",shape=folder]; |
paul@1039 | 692 | freebusy_cars_vole [label="...recording schedule for\nvincent.vole@example.com",shape=folder]; |
paul@1039 | 693 | } |
paul@1039 | 694 | |
paul@1039 | 695 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1039 | 696 | |
paul@1039 | 697 | subgraph { |
paul@1039 | 698 | rank=same; |
paul@1039 | 699 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 700 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1039 | 701 | } |
paul@1039 | 702 | |
paul@1039 | 703 | add_to_quota_freebusy [label="Add to quota free/busy",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1039 | 704 | remove_from_quota_freebusy [label="Remove from quota free/busy",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1039 | 705 | |
paul@1039 | 706 | mail_cadillac -> schedule_across_quota; |
paul@1039 | 707 | mail_pontiac -> schedule_across_quota -> schedule -> accept; |
paul@1039 | 708 | schedule_across_quota -> decline [style=dashed]; |
paul@1039 | 709 | schedule -> add_to_quota_freebusy -> quota_cars -> freebusy_cars_vole; |
paul@1039 | 710 | freebusy_cars_vole -> schedule_across_quota; |
paul@1039 | 711 | |
paul@1039 | 712 | cancel -> remove_from_quota_freebusy -> freebusy_cars_vole; |
paul@1039 | 713 | } |
paul@1039 | 714 | }}} |
paul@1039 | 715 | |
paul@1039 | 716 | }}}} |
paul@1180 | 717 | |
paul@1180 | 718 | ==== Delegating Attendance ==== |
paul@1180 | 719 | |
paul@1180 | 720 | A number of resources may be regarded as interchangeable and can therefore |
paul@1180 | 721 | stand in for each other when they are unavailable. The iCalendar specification |
paul@1180 | 722 | supports the notion of delegation: the recipient of an event invitation may |
paul@1180 | 723 | delegate their attendance to other calendar user, informing that user and the |
paul@1180 | 724 | event organiser of this decision. |
paul@1180 | 725 | |
paul@1180 | 726 | To define such delegation relationships, a quota is first selected as the |
paul@1180 | 727 | repository of common scheduling information for a group of resources. Then, |
paul@1180 | 728 | the members of the group are defined as delegates. This can be done using a |
paul@1180 | 729 | tool provided for this purpose. For example: |
paul@1180 | 730 | |
paul@1180 | 731 | {{{ |
paul@1180 | 732 | cat <<EOF | tools/set_delegates.py 'cars' |
paul@1180 | 733 | mailto:resource-car-cadillac@example.com |
paul@1180 | 734 | mailto:resource-car-pontiac@example.com |
paul@1180 | 735 | EOF |
paul@1180 | 736 | }}} |
paul@1180 | 737 | |
paul@1180 | 738 | Here, two resources are defined that will delegate to each other if they |
paul@1180 | 739 | cannot attend an event according to their own schedule. |
paul@1180 | 740 | |
paul@1180 | 741 | {{{{#!table |
paul@1180 | 742 | '''Scheduling Functions''' || '''Decision Process''' |
paul@1180 | 743 | == |
paul@1180 | 744 | <style="vertical-align: top;"> |
paul@1180 | 745 | |
paul@1180 | 746 | {{{ |
paul@1180 | 747 | schedule_for_delegate cars |
paul@1180 | 748 | }}} |
paul@1180 | 749 | |
paul@1180 | 750 | || |
paul@1180 | 751 | |
paul@1180 | 752 | {{{#!graphviz |
paul@1180 | 753 | //format=svg |
paul@1180 | 754 | //transform=notugly |
paul@1180 | 755 | digraph scheduling_decisions { |
paul@1180 | 756 | node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Scheduling decisions"]; |
paul@1180 | 757 | edge [tooltip="Scheduling decisions"]; |
paul@1180 | 758 | |
paul@1180 | 759 | subgraph { |
paul@1180 | 760 | rank=same; |
paul@1180 | 761 | mail_cadillac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-cadillac@example.com",shape=folder,style=filled,fillcolor=cyan]; |
paul@1180 | 762 | mail_pontiac [label="Incoming mail\nfrom vincent.vole@example.com\nto resource-car-pontiac@example.com",shape=folder,style=filled,fillcolor=cyan]; |
paul@1180 | 763 | cancel [label="Incoming cancellation",shape=folder,style=filled,fillcolor=cyan]; |
paul@1180 | 764 | } |
paul@1180 | 765 | |
paul@1180 | 766 | subgraph { |
paul@1180 | 767 | rank=same; |
paul@1180 | 768 | schedule_for_delegate [label="Can be scheduled or delegated?",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1180 | 769 | quota_cars [label="Quota for cars",shape=folder]; |
paul@1180 | 770 | freebusy_cars_vole [label="...recording schedule for\nvincent.vole@example.com",shape=folder]; |
paul@1180 | 771 | } |
paul@1180 | 772 | |
paul@1180 | 773 | schedule [label="Schedule event for resource",shape=ellipse,style=filled,fillcolor=gold]; |
paul@1180 | 774 | |
paul@1180 | 775 | subgraph { |
paul@1180 | 776 | rank=same; |
paul@1180 | 777 | accept [label="Accept",shape=folder,style=filled,fillcolor=cyan]; |
paul@1180 | 778 | delegate [label="Delegate",shape=folder,style=filled,fillcolor=cyan]; |
paul@1180 | 779 | decline [label="Decline",shape=folder,style=filled,fillcolor=cyan]; |
paul@1180 | 780 | } |
paul@1180 | 781 | |
paul@1180 | 782 | add_to_quota [label="Add to quota",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1180 | 783 | remove_from_quota [label="Remove from quota",shape=ellipse,style=filled,fillcolor=darkorange]; |
paul@1180 | 784 | |
paul@1180 | 785 | mail_cadillac -> schedule_for_delegate; |
paul@1180 | 786 | mail_pontiac -> schedule_for_delegate -> schedule -> accept; |
paul@1180 | 787 | schedule_for_delegate -> delegate [style=dashed]; |
paul@1180 | 788 | schedule_for_delegate -> decline [style=dashed]; |
paul@1180 | 789 | schedule -> add_to_quota -> quota_cars -> freebusy_cars_vole; |
paul@1180 | 790 | freebusy_cars_vole -> schedule_for_delegate; |
paul@1180 | 791 | |
paul@1180 | 792 | cancel -> remove_from_quota -> freebusy_cars_vole; |
paul@1180 | 793 | } |
paul@1180 | 794 | }}} |
paul@1180 | 795 | |
paul@1180 | 796 | }}}} |
paul@1180 | 797 | |
paul@1180 | 798 | Note that it is generally more useful to have delegation decisions made on the |
paul@1180 | 799 | basis of many resources, which is what the journal entries for each quota |
paul@1180 | 800 | provides, but also for many organisers attempting to reserve those resources. |
paul@1180 | 801 | Although the journal for each quota may be divided up to administer quotas for |
paul@1180 | 802 | multiple groups of organisers, for the purposes of delegation - deciding |
paul@1180 | 803 | whether a resource is generally available, and deciding which other resource |
paul@1180 | 804 | would be available instead - a single group of all organisers is more desirable. |