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