1 = Resources = 2 3 In imip-agent, resources are a special kind of user that act upon requests 4 to schedule events and that perform such scheduling autonomously, meaning 5 that no human intervention is necessary when such resources receive messages 6 containing invitations. 7 8 By default, the [[../AgentPrograms|agent program]] responsible for resources 9 merely attempts to fit a received event into the resource's schedule. However, 10 in some organisations and environments, it is likely to be the case that other 11 policies are needed to ensure that a resource is not misused, overused or made 12 unnecessarily unavailable. 13 14 The [[../Preferences|preferences]] provide a way of controlling the behaviour 15 of resources, just as with any other kind of user, but certain preferences 16 are central to the configuration of resources. 17 18 <<TableOfContents(2,4)>> 19 20 == Scheduling Functions == 21 22 The [[../Preferences#scheduling_function|scheduling_function]] setting 23 indicates the behaviour of a resource when a valid request to schedule an 24 event has been received. By default, a value equivalent to the following is 25 employed: 26 27 {{{ 28 schedule_in_freebusy 29 }}} 30 31 As described above, this merely attempts to schedule an event in the free 32 periods of the resource's schedule. However, no attempt is made to reject the 33 booking of the resource according to the identity of the organiser. 34 35 === Identity Controls === 36 37 Although identity controls may be implemented in the e-mail system, 38 effectively preventing the messages from addresses other than those within 39 an organisation (for example) from being delivered to the resource, it is 40 possible to use scheduling functions to implement such controls instead. 41 42 ==== Same Domain Membership ==== 43 44 For instance, the following combines the default free/busy check with a 45 test that the organiser belongs to the same Internet mail domain (by using 46 the organiser's address): 47 48 {{{ 49 schedule_in_freebusy 50 same_domain_only 51 }}} 52 53 Note that if the first function is omitted, no check against the resource's 54 schedule will occur, so it is necessary to mention any such function in the 55 list. 56 57 ==== Access Control Lists ==== 58 59 A simple domain-related test may not be sufficient to control access to a 60 resource. Thus, another function is provided to exercise a finer degree of 61 control over event participants. For example: 62 63 {{{ 64 schedule_in_freebusy 65 access_control_list 66 }}} 67 68 To accompany this, the [[../Preferences#acl|acl]] setting in the 69 resource's preferences must be set, or if a separate file is more appropriate, 70 its full path may be given as an argument: 71 72 {{{ 73 schedule_in_freebusy 74 access_control_list /etc/imip-agent/resources.acl 75 }}} 76 77 Within the file provided by the setting or separate file, a list of rules 78 must describe the handling procedure for an event. For example: 79 80 {{{ 81 accept 82 }}} 83 84 This will merely accept all invitations, anyway. However, it may be 85 appropriate to prevent certain users from using resources. For example: 86 87 {{{ 88 accept 89 decline attendee simon.skunk@example.com 90 }}} 91 92 This example indicates that by default, invitations will be accepted, but if 93 one of the attendees of an event is `simon.skunk@example.com`, the invitation 94 will be declined. However, it may be the case that this rule should be 95 overridden under certain circumstances. For example: 96 97 {{{ 98 accept 99 decline attendee simon.skunk@example.com 100 accept organiser paul.boddie@example.com 101 }}} 102 103 Here, the stated organiser may still arrange a booking of the resource where 104 the previously-mentioned attendee is involved.