1 = Preferences = 2 3 The correspondence between user preferences (stored in user preference 4 directories) and the default settings (stored in `config.py`) is described 5 below. 6 7 || '''Preference''' || '''Default Setting''' || 8 || `LANG` || `LANG` || 9 || `add_method_response` || `ADD_RESPONSE_DEFAULT` || 10 || `event_refreshing` || `REFRESHING_DEFAULT` || 11 || `freebusy_bundling` || `BUNDLING_DEFAULT` || 12 || `freebusy_messages` || `NOTIFYING_DEFAULT` || 13 || `freebusy_offers` || `FREEBUSY_OFFER_DEFAULT` || 14 || `freebusy_publishing` || `PUBLISHING_DEFAULT` || 15 || `freebusy_sharing` || `SHARING_DEFAULT` || 16 || `incoming` || `INCOMING_DEFAULT` || 17 || `organiser_replacement` || `ORGANISER_REPLACEMENT_DEFAULT` || 18 || `participating` || `PARTICIPATING_DEFAULT` || 19 20 See the [[../Configuration|configuration guide]] for more information about 21 the `config.py` file. 22 23 == User Preference Settings == 24 25 <<TableOfContents(3,3)>> 26 27 Each of the user preferences or settings are stored in a separate file within 28 a dedicated preferences directory for each user, with the filename bearing the 29 name of the setting concerned. 30 31 === CN === 32 33 Default:: (none) 34 Alternatives:: (see below) 35 36 The common name of the user, employed in iCalendar objects and user 37 interfaces. 38 39 === LANG === 40 41 Default:: `en` (English) 42 Alternatives:: (any recognised and supported locale) 43 44 The language for messages and user interface text. 45 46 === TZID === 47 48 Default:: system timezone (see `/etc/timezone`) 49 Alternatives:: (any recognised Olson time zone identifier) 50 51 The default time zone/regime for calendars, new events and local times. 52 53 === add_method_response === 54 55 Default:: `refresh` 56 Alternatives:: (see below) 57 58 Indicate how `ADD` methods shall be responded to when received by a recipient: 59 60 {{{#!table 61 `add` || apply them to events as received 62 == 63 `ignore` || ignore attempts to add event occurrences 64 == 65 `refresh` || respond with a `REFRESH` message to obtain a proper request with 66 .. all event details 67 }}} 68 69 === event_refreshing === 70 71 Default:: `never` 72 Alternative:: `always` 73 74 Indicate whether messages requesting a refresh of event details shall be 75 handled automatically. If not, such messages will be passed on to the 76 recipient for their mail program to handle. 77 78 === freebusy_bundling === 79 80 Default:: `never` 81 Alternative:: `always` 82 83 Indicate whether to bundle free/busy details with other payloads such as 84 event and free/busy objects. The `freebusy_sharing` setting must be 85 configured for bundling to operate. 86 87 === freebusy_messages === 88 89 Default:: `none` 90 Alternative:: `notify` 91 92 Indicate whether recipients are notified about received free/busy payloads. 93 94 === freebusy_offers === 95 96 Default:: (none) 97 Alternative:: (see below) 98 99 Define the period for which free/busy offers are extended by participants 100 supporting this setting when counter-proposals are made during event 101 scheduling. 102 103 This setting requires a value indicating a duration as described in the 104 iCalendar format specification: 105 106 http://tools.ietf.org/html/rfc5545#section-3.3.6 107 108 For example: 109 110 || `PT10M` || extend scheduling offers for 10 minutes || 111 || `PT600S` || extend scheduling offers for 600 seconds (10 minutes) || 112 || `PT1D` || extend offers for 1 day || 113 114 === freebusy_publishing === 115 116 Default:: `no` 117 Alternative:: `publish` 118 119 Indicate whether to publish free/busy details as Web resources. The 120 `freebusy_sharing` setting must be configured for publishing to operate. 121 122 === freebusy_sharing === 123 124 Default:: `no` 125 Alternative:: `share` 126 127 Share free/busy details generally: 128 129 * bundling in e-mail messages if bundling is configured 130 * responding to free/busy requests via e-mail 131 * publishing as Web resources if a static Web resource is configured and if 132 publishing is configured 133 134 === incoming === 135 136 Default:: `summary-wraps-message` 137 Alternatives:: (see below) 138 139 Define how incoming event messages are delivered to recipients: 140 141 {{{#!table 142 `message-only` 143 || deliver only the incoming message as it was received 144 == 145 `message-then-summary` 146 || deliver the message first followed by a summary message 147 == 148 `summary-then-message` 149 || deliver a summary first followed by the message 150 == 151 `summary-only` 152 || deliver only a summary of the message 153 == 154 `summary-wraps-message` 155 || deliver a summary that includes the original message as an attachment 156 }}} 157 158 === organiser_replacement === 159 160 Default:: `attendee` 161 Alternatives:: (see below) 162 163 Indicate whether the organiser of an event can be replaced and the nature of 164 any replacement: 165 166 {{{#!table 167 `any` || any identity, regardless of whether it is already present or even 168 .. previously unknown, may become the organiser 169 == 170 `attendee` || any new organiser must be a previously-recognised attendee 171 == 172 `never` || forbid the replacement of an event's organiser 173 }}} 174 175 === participating === 176 177 Default:: `participate` 178 Alternative:: `no` 179 180 Indicate whether a recipient participates in the calendar system. Note that 181 participation by default occurs because the handler programs will be defined 182 in the mail system for recipients fulfilling certain criteria; other 183 recipients will be handled in other ways. Thus, initial non-participation must 184 be defined by initialising this setting to "no" for all eligible users, if 185 this is the general policy on initial calendar system participation. 186 187 === permitted_times === 188 189 Default:: (none) 190 Alternatives:: (see below) 191 192 Define the time values at which events can be scheduled. In its simplest form, 193 this indicates the resolution of a calendar for a participant supporting this 194 setting, with the given minute values being those allowed for the start and 195 end of an event. This setting requires a value of one of the following forms: 196 197 {{{ 198 <minute values> 199 <hour values>:<minute values> 200 <hour values>:<minute values>:<second values> 201 }}} 202 203 Each list of values is a comma-separated collection of permissible values for 204 the unit of time being constrained. Any unspecified list is taken to permit 205 all normally permissible values for that unit of time. For example: 206 207 {{{#!table 208 `0,15,30,45` || every 15 minutes from the start of each hour 209 == 210 `10,12,14,16:0,20,40` || every 20 minutes from 10:00 until 16:40 inclusive 211 == 212 `12::0,30` || every 30 seconds from the start of each minute 213 .. during the period from 12:00:00 until 12:59:30 214 .. inclusive 215 }}} 216 217 The purpose of this setting is not necessarily to impose availability 218 constraints but instead to impose a "grid" to which event start and end points 219 shall be "locked". 220 221 The values are interpreted in the local time of the participant. Thus, a time 222 represented in UTC may have apparently inappropriate hour (and for some zones) 223 minute values that correspond to permitted values in this participant's own 224 time zone. 225 226 === scheduling_function === 227 228 Default:: `schedule_in_freebusy` 229 Alternatives:: (see below) 230 231 Indicates the scheduling function used by resources to find an appropriate 232 period for an event. The `imiptools.handlers.scheduling` module contains the 233 built-in scheduling functions which include the following: 234 235 {{{#!table 236 `schedule_in_freebusy` || accept an invitation if the event periods are free 237 .. according to the free/busy records for the resource; 238 .. decline otherwise 239 == 240 `schedule_corrected_in_freebusy` || correct periods in an event according to 241 .. the permitted_times setting (see above), 242 .. then attempt to schedule the event according to the 243 .. free/busy records for the resource 244 == 245 `schedule_next_available_in_freebusy` || correct periods in an event according 246 .. to the permitted_times setting (see 247 .. above), if configured, and attempt to schedule the 248 .. event according to the free/busy records for the 249 .. resource and for any attendees for whom records are 250 .. available, seeking the next available free period for 251 .. each period that conflicts with an existing event 252 }}} 253 254 The scheduling mechanism can be extended by implementing additional scheduling 255 functions or by extending the handler framework directly.