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