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. See the [[../FilesystemUsage|filesystem guide]] 30 for more information. 31 32 === CN === 33 34 Default:: (none) 35 Alternatives:: (see below) 36 37 The common name of the user, employed in iCalendar objects and user 38 interfaces. 39 40 === LANG === 41 42 Default:: `en` (English) 43 Alternatives:: (any recognised and supported locale) 44 45 The language for messages and user interface text. 46 47 === TZID === 48 49 Default:: system timezone (see `/etc/timezone`) 50 Alternatives:: (any recognised Olson time zone identifier) 51 52 The default time zone/regime for calendars, new events and local times. 53 54 === acl === 55 56 Default:: (none) 57 Alternatives:: (see below) 58 59 Provides an access control list for the `access_control_list` scheduling 60 function, invoked using the `scheduling_functions` setting. An access control 61 list consists of a collection of lines of text describing the handling policy 62 for an incoming invitation. 63 64 {{{#!table 65 `accept` || indicates that if no rule matches, the invitation will be accepted 66 .. (provisionally) 67 == 68 `decline` ||<rowspan="2"> indicates that if no rule matches, the invitation 69 .. will be declined (provisionally) 70 == 71 `reject` 72 == 73 `accept` ''`role`'' ''`identity`'' || indicates that where the given 74 .. ''`identity`'' exists in the given 75 .. ''`role`'' in the event, and unless a subsequent rule contradicts 76 .. this result, the invitation will be accepted (provisionally) 77 == 78 `decline` ''`role`'' ''`identity`'' ||<rowspan="2"> indicates that where the 79 .. given ''`identity`'' exists 80 .. in the given ''`role`'' in the event, and unless a subsequent rule 81 .. contradicts this result, the invitation will be declined 82 .. (provisionally) 83 84 == 85 `reject` ''`role`'' ''`identity`'' 86 }}} 87 88 In the above, `role` is either `organiser` (or `organizer`) or `attendee`; 89 `identity` is an address or URL. 90 91 Note that even if an accepted result is returned by the `access_control_list` 92 scheduling function, other functions that follow it in the list of functions 93 may overturn this result. 94 95 See the [[../Resources|resources guide]] for examples and more information. 96 97 === add_method_response === 98 99 Default:: `refresh` 100 Alternatives:: (see below) 101 102 Indicate how `ADD` methods shall be responded to when received by a recipient: 103 104 {{{#!table 105 `add` || apply them to events as received 106 == 107 `ignore` || ignore attempts to add event occurrences 108 == 109 `refresh` || respond with a `REFRESH` message to obtain a proper request with 110 .. all event details 111 }}} 112 113 === confirmation_function === 114 115 Default:: (none) 116 Alternatives:: (see below) 117 118 Indicates the confirmation functions used by [[../Resources|resources]] to be 119 invoked when an event is scheduled. Such functions support certain scheduling 120 functions that require a record of scheduling activity. 121 122 The `imiptools.handlers.scheduling` module contains the built-in confirmation 123 functions which include the following: 124 125 {{{#!table 126 `add_to_quota` || add the details of an event to quota records 127 }}} 128 129 See also `retraction_function` and `scheduling_function`. 130 131 === event_refreshing === 132 133 Default:: `never` 134 Alternative:: `always` 135 136 Indicate whether messages requesting a refresh of event details shall be 137 handled automatically. If not, such messages will be passed on to the 138 recipient for their mail program to handle. 139 140 === freebusy_bundling === 141 142 Default:: `never` 143 Alternative:: `always` 144 145 Indicate whether to bundle free/busy details with other payloads such as 146 event and free/busy objects. The `freebusy_sharing` setting must be 147 configured for bundling to operate. 148 149 === freebusy_messages === 150 151 Default:: `none` 152 Alternative:: `notify` 153 154 Indicate whether recipients are notified about received free/busy payloads. 155 156 === freebusy_offers === 157 158 Default:: (none) 159 Alternative:: (see below) 160 161 Define the period for which free/busy offers are extended by participants 162 supporting this setting when counter-proposals are made during event 163 scheduling. 164 165 This setting requires a value indicating a duration as described in the 166 iCalendar format specification: 167 168 http://tools.ietf.org/html/rfc5545#section-3.3.6 169 170 For example: 171 172 || `PT10M` || extend scheduling offers for 10 minutes || 173 || `PT600S` || extend scheduling offers for 600 seconds (10 minutes) || 174 || `PT1D` || extend offers for 1 day || 175 176 === freebusy_publishing === 177 178 Default:: `no` 179 Alternative:: `publish` 180 181 Indicate whether to publish free/busy details as Web resources. The 182 `freebusy_sharing` setting must be configured for publishing to operate. 183 184 === freebusy_sharing === 185 186 Default:: `no` 187 Alternative:: `share` 188 189 Share free/busy details generally: 190 191 * bundling in e-mail messages if bundling is configured 192 * responding to free/busy requests via e-mail 193 * publishing as Web resources if a static Web resource is configured and if 194 publishing is configured 195 196 === incoming === 197 198 Default:: `summary-wraps-message` 199 Alternatives:: (see below) 200 201 Define how incoming event messages are delivered to recipients: 202 203 {{{#!table 204 `message-only` 205 || deliver only the incoming message as it was received 206 == 207 `message-then-summary` 208 || deliver the message first followed by a summary message 209 == 210 `summary-then-message` 211 || deliver a summary first followed by the message 212 == 213 `summary-only` 214 || deliver only a summary of the message 215 == 216 `summary-wraps-message` 217 || deliver a summary that includes the original message as an attachment 218 }}} 219 220 === organiser_replacement === 221 222 Default:: `attendee` 223 Alternatives:: (see below) 224 225 Indicate whether the organiser of an event can be replaced and the nature of 226 any replacement: 227 228 {{{#!table 229 `any` || any identity, regardless of whether it is already present or even 230 .. previously unknown, may become the organiser 231 == 232 `attendee` || any new organiser must be a previously-recognised attendee 233 == 234 `never` || forbid the replacement of an event's organiser 235 }}} 236 237 === participating === 238 239 Default:: `participate` 240 Alternative:: `no` 241 242 Indicate whether a recipient participates in the calendar system. Note that 243 participation by default occurs because the handler programs will be defined 244 in the mail system for recipients fulfilling certain criteria; other 245 recipients will be handled in other ways. Thus, initial non-participation must 246 be defined by initialising this setting to "no" for all eligible users, if 247 this is the general policy on initial calendar system participation. 248 249 === permitted_times === 250 251 Default:: (none) 252 Alternatives:: (see below) 253 254 Define the time values at which events can be scheduled. In its simplest form, 255 this indicates the resolution of a calendar for a participant supporting this 256 setting, with the given minute values being those allowed for the start and 257 end of an event. This setting requires a value of one of the following forms: 258 259 {{{ 260 <minute values> 261 <hour values>:<minute values> 262 <hour values>:<minute values>:<second values> 263 }}} 264 265 Each list of values is a comma-separated collection of permissible values for 266 the unit of time being constrained. Any unspecified list is taken to permit 267 all normally permissible values for that unit of time. For example: 268 269 {{{#!table 270 `0,15,30,45` || every 15 minutes from the start of each hour 271 == 272 `10,12,14,16:0,20,40` || every 20 minutes from 10:00 until 16:40 inclusive 273 == 274 `12::0,30` || every 30 seconds from the start of each minute 275 .. during the period from 12:00:00 until 12:59:30 276 .. inclusive 277 }}} 278 279 The purpose of this setting is not necessarily to impose availability 280 constraints but instead to impose a "grid" to which event start and end points 281 shall be "locked". 282 283 The values are interpreted in the local time of the participant. Thus, a time 284 represented in UTC may have apparently inappropriate hour (and for some zones) 285 minute values that correspond to permitted values in this participant's own 286 time zone. 287 288 === retraction_function === 289 290 Default:: (none) 291 Alternatives:: (see below) 292 293 Indicates the retraction functions used by [[../Resources|resources]] to be 294 invoked when an event is cancelled. Such functions support certain scheduling 295 functions that require a record of scheduling activity. 296 297 The `imiptools.handlers.scheduling` module contains the built-in retraction 298 functions which include the following: 299 300 {{{#!table 301 `remove_from_quota` || remove the details of an event from quota records 302 }}} 303 304 See also `confirmation_function` and `scheduling_function`. 305 306 === scheduling_function === 307 308 Default:: `schedule_in_freebusy` 309 Alternatives:: (see below) 310 311 Indicates the scheduling functions used by [[../Resources|resources]] to find 312 an appropriate period for an event, with each function to be applied to a 313 scheduling request appearing on a separate line, optionally accompanied by 314 arguments controlling the behaviour of the function. 315 316 The `imiptools.handlers.scheduling` module contains the built-in scheduling 317 functions which include the following: 318 319 {{{#!table 320 `access_control_list` || use an access control list provided by a file whose 321 .. name is given as an argument, accepting or declining 322 .. the invitation according to the indicated rules 323 .. (described in the [[../Resources|resources guide]]) 324 == 325 `check_quota` || accept an invitation only if the organiser does not 326 .. exceed their quota allowance for bookings 327 .. (described in the [[../Resources|resources guide]]) 328 == 329 `same_domain_only` || accept an invitation only if the organiser employs an 330 .. address in the same domain as the resource 331 == 332 `schedule_in_freebusy` || accept an invitation if the event periods are free 333 .. according to the free/busy records for the resource; 334 .. decline otherwise 335 == 336 `schedule_corrected_in_freebusy` || correct periods in an event according to 337 .. the permitted_times setting (see above), 338 .. then attempt to schedule the event according to the 339 .. free/busy records for the resource 340 == 341 `schedule_next_available_in_freebusy` || correct periods in an event according 342 .. to the permitted_times setting (see 343 .. above), if configured, and attempt to schedule the 344 .. event according to the free/busy records for the 345 .. resource and for any attendees for whom records are 346 .. available, seeking the next available free period for 347 .. each period that conflicts with an existing event 348 }}} 349 350 The scheduling mechanism can be extended by implementing additional scheduling 351 functions or by extending the handler framework directly. 352 353 See also `confirmation_function` and `retraction_function`.