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` ||<rowspan="2"> add the details of an event to quota 127 .. records for the indicated quota group 128 == 129 `add_to_quota` ''`quota-group`'' 130 == 131 `add_to_quota_freebusy` ||<rowspan="2"> add the details of an event to 132 .. free/busy records stored by the indicated quota 133 .. group 134 == 135 `add_to_quota_freebusy` ''`quota-group`'' 136 }}} 137 138 See also `retraction_function` and `scheduling_function`. 139 140 === event_refreshing === 141 142 Default:: `never` 143 Alternative:: `always` 144 145 Indicate whether messages requesting a refresh of event details shall be 146 handled automatically. If not, such messages will be passed on to the 147 recipient for their mail program to handle. 148 149 === freebusy_bundling === 150 151 Default:: `never` 152 Alternative:: `always` 153 154 Indicate whether to bundle free/busy details with other payloads such as 155 event and free/busy objects. The `freebusy_sharing` setting must be 156 configured for bundling to operate. 157 158 === freebusy_messages === 159 160 Default:: `none` 161 Alternative:: `notify` 162 163 Indicate whether recipients are notified about received free/busy payloads. 164 165 === freebusy_offers === 166 167 Default:: (none) 168 Alternative:: (see below) 169 170 Define the period for which free/busy offers are extended by participants 171 supporting this setting when counter-proposals are made during event 172 scheduling. 173 174 This setting requires a value indicating a duration as described in the 175 iCalendar format specification: 176 177 http://tools.ietf.org/html/rfc5545#section-3.3.6 178 179 For example: 180 181 || `PT10M` || extend scheduling offers for 10 minutes || 182 || `PT600S` || extend scheduling offers for 600 seconds (10 minutes) || 183 || `PT1D` || extend offers for 1 day || 184 185 === freebusy_publishing === 186 187 Default:: `no` 188 Alternative:: `publish` 189 190 Indicate whether to publish free/busy details as Web resources. The 191 `freebusy_sharing` setting must be configured for publishing to operate. 192 193 === freebusy_sharing === 194 195 Default:: `no` 196 Alternative:: `share` 197 198 Share free/busy details generally: 199 200 * bundling in e-mail messages if bundling is configured 201 * responding to free/busy requests via e-mail 202 * publishing as Web resources if a static Web resource is configured and if 203 publishing is configured 204 205 === incoming === 206 207 Default:: `summary-wraps-message` 208 Alternatives:: (see below) 209 210 Define how incoming event messages are delivered to recipients: 211 212 {{{#!table 213 `message-only` 214 || deliver only the incoming message as it was received 215 == 216 `message-then-summary` 217 || deliver the message first followed by a summary message 218 == 219 `summary-then-message` 220 || deliver a summary first followed by the message 221 == 222 `summary-only` 223 || deliver only a summary of the message 224 == 225 `summary-wraps-message` 226 || deliver a summary that includes the original message as an attachment 227 }}} 228 229 === organiser_replacement === 230 231 Default:: `attendee` 232 Alternatives:: (see below) 233 234 Indicate whether the organiser of an event can be replaced and the nature of 235 any replacement: 236 237 {{{#!table 238 `any` || any identity, regardless of whether it is already present or even 239 .. previously unknown, may become the organiser 240 == 241 `attendee` || any new organiser must be a previously-recognised attendee 242 == 243 `never` || forbid the replacement of an event's organiser 244 }}} 245 246 === participating === 247 248 Default:: `participate` 249 Alternative:: `no` 250 251 Indicate whether a recipient participates in the calendar system. Note that 252 participation by default occurs because the handler programs will be defined 253 in the mail system for recipients fulfilling certain criteria; other 254 recipients will be handled in other ways. Thus, initial non-participation must 255 be defined by initialising this setting to "no" for all eligible users, if 256 this is the general policy on initial calendar system participation. 257 258 === permitted_times === 259 260 Default:: (none) 261 Alternatives:: (see below) 262 263 Define the time values at which events can be scheduled. In its simplest form, 264 this indicates the resolution of a calendar for a participant supporting this 265 setting, with the given minute values being those allowed for the start and 266 end of an event. This setting requires a value of one of the following forms: 267 268 {{{ 269 <minute values> 270 <hour values>:<minute values> 271 <hour values>:<minute values>:<second values> 272 }}} 273 274 Each list of values is a comma-separated collection of permissible values for 275 the unit of time being constrained. Any unspecified list is taken to permit 276 all normally permissible values for that unit of time. For example: 277 278 {{{#!table 279 `0,15,30,45` || every 15 minutes from the start of each hour 280 == 281 `10,12,14,16:0,20,40` || every 20 minutes from 10:00 until 16:40 inclusive 282 == 283 `12::0,30` || every 30 seconds from the start of each minute 284 .. during the period from 12:00:00 until 12:59:30 285 .. inclusive 286 }}} 287 288 The purpose of this setting is not necessarily to impose availability 289 constraints but instead to impose a "grid" to which event start and end points 290 shall be "locked". 291 292 The values are interpreted in the local time of the participant. Thus, a time 293 represented in UTC may have apparently inappropriate hour (and for some zones) 294 minute values that correspond to permitted values in this participant's own 295 time zone. 296 297 === retraction_function === 298 299 Default:: (none) 300 Alternatives:: (see below) 301 302 Indicates the retraction functions used by [[../Resources|resources]] to be 303 invoked when an event is cancelled. Such functions support certain scheduling 304 functions that require a record of scheduling activity. 305 306 The `imiptools.handlers.scheduling` module contains the built-in retraction 307 functions which include the following: 308 309 {{{#!table 310 `remove_from_quota` ||<rowspan="2"> remove the details of an event from 311 .. quota records for the indicated quota group 312 == 313 `remove_from_quota` ''`quota-group`'' 314 == 315 `remove_from_quota_freebusy` ||<rowspan="2"> remove the details of an event 316 .. from free/busy records stored by the 317 .. indicated quota group 318 == 319 `remove_from_quota_freebusy` ''`quota-group`'' 320 }}} 321 322 See also `confirmation_function` and `scheduling_function`. 323 324 === scheduling_function === 325 326 Default:: `schedule_in_freebusy` 327 Alternatives:: (see below) 328 329 Indicates the scheduling functions used by [[../Resources|resources]] to find 330 an appropriate period for an event, with each function to be applied to a 331 scheduling request appearing on a separate line, optionally accompanied by 332 arguments controlling the behaviour of the function. 333 334 The `imiptools.handlers.scheduling` module contains the built-in scheduling 335 functions which include the following: 336 337 {{{#!table 338 `access_control_list` || use an access control list provided by a file whose 339 .. name is given as an argument, accepting or declining 340 .. the invitation according to the indicated rules 341 .. (described in the [[../Resources|resources guide]]) 342 == 343 `check_quota` || accept an invitation only if the organiser does not 344 .. exceed their quota allowance for bookings for the 345 .. indicated quota group 346 .. (described in the [[../Resources|resources guide]]) 347 == 348 `schedule_across_quota`|| accept an invitation only if the organiser has not 349 .. reserved a resource for a conflicting period in any 350 .. other resource belonging to the indicated quota group 351 .. (described in the [[../Resources|resources guide]]) 352 == 353 `same_domain_only` || accept an invitation only if the organiser employs an 354 .. address in the same domain as the resource 355 == 356 `schedule_in_freebusy` || accept an invitation if the event periods are free 357 .. according to the free/busy records for the resource; 358 .. decline otherwise 359 == 360 `schedule_corrected_in_freebusy` || correct periods in an event according to 361 .. the permitted_times setting (see above), 362 .. then attempt to schedule the event according to the 363 .. free/busy records for the resource 364 == 365 `schedule_next_available_in_freebusy` || correct periods in an event according 366 .. to the permitted_times setting (see 367 .. above), if configured, and attempt to schedule the 368 .. event according to the free/busy records for the 369 .. resource and for any attendees for whom records are 370 .. available, seeking the next available free period for 371 .. each period that conflicts with an existing event 372 }}} 373 374 The scheduling mechanism can be extended by implementing additional scheduling 375 functions or by extending the handler framework directly. 376 377 See also `confirmation_function` and `retraction_function`.