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