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@1032 | 27 | {{{ |
paul@1032 | 28 | schedule_in_freebusy |
paul@1032 | 29 | }}} |
paul@1032 | 30 | |
paul@1032 | 31 | As described above, this merely attempts to schedule an event in the free |
paul@1032 | 32 | periods of the resource's schedule. However, no attempt is made to reject the |
paul@1032 | 33 | booking of the resource according to the identity of the organiser. |
paul@1032 | 34 | |
paul@1032 | 35 | === Identity Controls === |
paul@1032 | 36 | |
paul@1032 | 37 | Although identity controls may be implemented in the e-mail system, |
paul@1032 | 38 | effectively preventing the messages from addresses other than those within |
paul@1032 | 39 | an organisation (for example) from being delivered to the resource, it is |
paul@1032 | 40 | possible to use scheduling functions to implement such controls instead. |
paul@1032 | 41 | |
paul@1032 | 42 | ==== Same Domain Membership ==== |
paul@1032 | 43 | |
paul@1032 | 44 | For instance, the following combines the default free/busy check with a |
paul@1032 | 45 | test that the organiser belongs to the same Internet mail domain (by using |
paul@1032 | 46 | the organiser's address): |
paul@1032 | 47 | |
paul@1032 | 48 | {{{ |
paul@1032 | 49 | schedule_in_freebusy |
paul@1032 | 50 | same_domain_only |
paul@1032 | 51 | }}} |
paul@1032 | 52 | |
paul@1032 | 53 | Note that if the first function is omitted, no check against the resource's |
paul@1032 | 54 | schedule will occur, so it is necessary to mention any such function in the |
paul@1032 | 55 | list. |
paul@1032 | 56 | |
paul@1032 | 57 | ==== Access Control Lists ==== |
paul@1032 | 58 | |
paul@1032 | 59 | A simple domain-related test may not be sufficient to control access to a |
paul@1032 | 60 | resource. Thus, another function is provided to exercise a finer degree of |
paul@1032 | 61 | control over event participants. For example: |
paul@1032 | 62 | |
paul@1032 | 63 | {{{ |
paul@1032 | 64 | schedule_in_freebusy |
paul@1032 | 65 | access_control_list |
paul@1032 | 66 | }}} |
paul@1032 | 67 | |
paul@1032 | 68 | To accompany this, the [[../Preferences#acl|acl]] setting in the |
paul@1032 | 69 | resource's preferences must be set, or if a separate file is more appropriate, |
paul@1032 | 70 | its full path may be given as an argument: |
paul@1032 | 71 | |
paul@1032 | 72 | {{{ |
paul@1032 | 73 | schedule_in_freebusy |
paul@1032 | 74 | access_control_list /etc/imip-agent/resources.acl |
paul@1032 | 75 | }}} |
paul@1032 | 76 | |
paul@1032 | 77 | Within the file provided by the setting or separate file, a list of rules |
paul@1032 | 78 | must describe the handling procedure for an event. For example: |
paul@1032 | 79 | |
paul@1032 | 80 | {{{ |
paul@1032 | 81 | accept |
paul@1032 | 82 | }}} |
paul@1032 | 83 | |
paul@1032 | 84 | This will merely accept all invitations, anyway. However, it may be |
paul@1032 | 85 | appropriate to prevent certain users from using resources. For example: |
paul@1032 | 86 | |
paul@1032 | 87 | {{{ |
paul@1032 | 88 | accept |
paul@1032 | 89 | decline attendee simon.skunk@example.com |
paul@1032 | 90 | }}} |
paul@1032 | 91 | |
paul@1032 | 92 | This example indicates that by default, invitations will be accepted, but if |
paul@1032 | 93 | one of the attendees of an event is `simon.skunk@example.com`, the invitation |
paul@1032 | 94 | will be declined. However, it may be the case that this rule should be |
paul@1032 | 95 | overridden under certain circumstances. For example: |
paul@1032 | 96 | |
paul@1032 | 97 | {{{ |
paul@1032 | 98 | accept |
paul@1032 | 99 | decline attendee simon.skunk@example.com |
paul@1032 | 100 | accept organiser paul.boddie@example.com |
paul@1032 | 101 | }}} |
paul@1032 | 102 | |
paul@1032 | 103 | Here, the stated organiser may still arrange a booking of the resource where |
paul@1032 | 104 | the previously-mentioned attendee is involved. |