zimbra_wsdl 0.0.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
data/doc/soap.txt ADDED
@@ -0,0 +1,3554 @@
1
+
2
+ REST URL for requesting content:
3
+
4
+ http://server/service/home/[˜][{username}]/[{folder}]?[{query-params}]
5
+ fmt={ics, csv, etc}
6
+ charset={Windows-31J, GBK, etc, default is UTF-8}
7
+ id={item-id}
8
+ imap_id={item-imap-id}
9
+ part={mime-part}
10
+ query={search-query}
11
+ types={types} // when searching
12
+ auth={auth-types}
13
+ start={time}
14
+ end={time}
15
+ sync="1"
16
+
17
+ {types} = comma-separated list. Legal values are:
18
+ appointment|chat|contact|conversation|document|
19
+ message|tag|task|wiki
20
+ (default is "conversation")
21
+
22
+ {auth-types} = comma-separated list. Legal values are:
23
+ co cookie
24
+ ba basic auth
25
+ nsc do not set a cookie when using basic auth
26
+ (default is "co,ba", i.e. check both)
27
+
28
+ {time} = (time in milliseconds) |
29
+ YYYY/dd/mm |
30
+ mm/dd/YYYY |
31
+ [-]nnnn{minute,hour,day,week,month,year} // relative
32
+
33
+ ----------------------
34
+
35
+ URL for posting to SOAP is:
36
+
37
+ /service/soap/
38
+
39
+ -------------------------------
40
+
41
+ urn:zimbra -- top-level namespace for global attributes/elements
42
+
43
+
44
+ <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
45
+ <soap:Header>
46
+ <context xmlns="urn:zimbra">
47
+ [<authToken>...</authToken>]
48
+ [<authTokenControl voidOnExpired="1"/>]
49
+ [<session [id="{returned-from-server-in-last-response}" [seq="{highest_notification_received}"] [type="admin"]/>]
50
+ [<account by="name|id">{account-name-or-id}</account>]
51
+ [<change token="{change-id}" [type="mod|new"]/>]
52
+ [<targetServer>{proxy-target-server-id}</targetServer>]
53
+ [<userAgent name="{client-name}" [version="{client-version}"]/>]
54
+ [<via>{request-ip(user-agent)[,...]}</via>
55
+ [<format type="{response-format}" />]
56
+ </context>
57
+ </soap:Header>
58
+ <soap:Body>
59
+ <FooRequest ... [requestId="{client-generated-id}"]>
60
+ </FooRequest>
61
+ </soap:Body>
62
+ </soap:Envelope>
63
+
64
+ Notification Reliability
65
+ To ensure that the client receives all notifications, the client
66
+ must send the highest known notification ID (the highest <notify>
67
+ block that the client has received and processed) so that the server
68
+ can discard them once it knows they have been received. If the client
69
+ is capable of sending multiple overlapping requests, the client is
70
+ responsible for making sure that notifications are not applied more
71
+ than once even if they are received more than one time.
72
+
73
+ Race Conditions
74
+
75
+ To avoid race conditions, the client may specify the highest change ID
76
+ that it knows about in the <change> header element. The default behavior
77
+ (type="mod") will cause mail.MODIFY_CONFLICT to be thrown if we try to
78
+ modify an object that has been touched (flags, tags, folders, etc.) since
79
+ the specified change ID. Alternatively, type="new" will throw
80
+ mail.MODIFY_CONFLICT if we try to modify an object that has been created
81
+ or whose content has been modified since the specified change ID.
82
+
83
+ In general, the sync client will use type="mod" and the web client will
84
+ use type="new".
85
+
86
+ Proxy Mechanism
87
+
88
+ The targetServer info is a proxy mechanism to allow a browser client to
89
+ send requests to multiple servers. This is primarily useful for admin
90
+ commands, but the mechanism is available for all commands. Proxying is
91
+ needed because some admin commands must be sent to the server being
92
+ affected but the browser admin client can only talk to the server it
93
+ originally logged on to. (JavaScript security restriction) If
94
+ <targetServer> element is missing, the command is executed on the local
95
+ server. If the target server specified is the local server, the command
96
+ is executed locally. Otherwise, it is proxied. The server is specified
97
+ by id, not by name.
98
+
99
+ Sessions
100
+
101
+ The server's default is disabling sessions for every SOAP request.
102
+ Clients that desire notification must explicitly request that the server
103
+ maintain a session for them. This is done by specifying a <session/>
104
+ element in the request.
105
+
106
+ When sessions are explicitly requested by the client, the server
107
+ will return the client's active session ID in the response's <session/>
108
+ header element. If this session ID is different from the one sent by the
109
+ client (or if the client requested a new session by including just a bare
110
+ "<session/>" inn the header), the client should assume the old session
111
+ (if any) has expired and immediately start using the returned session ID.
112
+
113
+ If a new session is created (due to no session ID being supplied in the request
114
+ or the old session timing out), the response context header will contain a
115
+ <refresh> block containing the current set of tags and folders. If there
116
+ have been any changes to the mailbox since the last soap operation (including
117
+ changes made due to this operation), there will also be a <notify> block in
118
+ the response context containing information on the deleted, created, and
119
+ modified items in the mailbox. (Note that a session will not return any
120
+ notifications if <nonotify/> was ever specified in a <context> request
121
+ element involving the session.) If there is a session, there will be a
122
+ <change> element specifying the last change ID on the server.
123
+
124
+ - deleted has just id
125
+ - created has full ToXML item dump
126
+ - modified has type/id, modified fields
127
+
128
+ <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
129
+ [<soap:Header>
130
+ <context xmlns="urn:zimbra">
131
+ <session id="{session-id}" [type="admin"]/>
132
+ <change token="{change-id}"/>
133
+ [<refresh>
134
+ <version>{server-version-string}</version>
135
+ <mbx s="{bytes-used}" [acct="{remote-mailbox-owner-id}"]/>
136
+ <tags>
137
+ <-- all tags listed -->
138
+ </tags>
139
+ <folder id="1">
140
+ <folder .../>
141
+ <folder ...>
142
+ <folder .../>
143
+ </folder>
144
+ <folder .../>
145
+ </folder>
146
+ </refresh>]
147
+ [<notify seq="sequence-number">
148
+ <deleted id="665,66,452,883"/>
149
+ <created>
150
+ <tag id="66" name="phlox" u="8"/>
151
+ <folder id="4353" name="a&p" u="2" l="1"/>
152
+ <folder id="4356" name="subfolder" u="2" l="4353"/>
153
+ <link id="1" name="new-mount-point" l="1" n="6" u="1" f="u" owner="user1@example.com" zid="151bd192-e19a-40be-b8c9-259b21ffac48" rid="2" oname="user1folder">
154
+ <folder id="151bd192-e19a-40be-b8c9-259b21ffac48:260" name="remote-subfolder" n="43" l="151bd192-e19a-40be-b8c9-259b21ffac48:2"/>
155
+ </link>
156
+ </created>
157
+ <modified>
158
+ <tag id="65" u="0"/>
159
+ <m id="553" f="ua"/>
160
+ </modified>
161
+ </notify>]+
162
+ </context>
163
+ <soap:/Header>]
164
+ <soap:Body>
165
+ <FooResponse ... [requestId="{client-generated-id}"]>
166
+ </FooResponse>
167
+ </soap:Body>
168
+ </soap:Envelope>
169
+
170
+
171
+
172
+ NOTES: The requestId="..." attribute is optional in the request body. If present, the server will
173
+ include it in the response body element.
174
+
175
+ batch requests:
176
+
177
+ <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
178
+ <soap:Header>
179
+ <context xmlns="urn:zimbra">
180
+ <authToken>...</authToken>
181
+ [<session [id="{returned-from-server-in-last-response}"]/>]
182
+ [<account by="name|id">{account-name-or-id}</account>]
183
+ [<change token="{change-id}" [type="mod|new"]/>]
184
+ </context>
185
+ </soap:Header>
186
+ <soap:Body>
187
+ <BatchRequest xmlns="urn:zimbra" onerror="continue*|stop">
188
+ <FooRequest requestId="1">
189
+ </FooRequest>
190
+ <BarRequest requestId="2">
191
+ </BarRequest>
192
+ </BatchRequest>
193
+ </soap:Body>
194
+ </soap:Envelope>
195
+
196
+ response:
197
+
198
+ <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
199
+ [<soap:Header>
200
+ <context xmlns="urn:zimbra">
201
+ <session id="{session-id}" [type="admin"]>
202
+ [<refresh>
203
+ <mbx s="{bytes-used}" [acct="{remote-mailbox-owner-id}"]/>
204
+ <tags>
205
+ <-- all tags listed -->
206
+ </tags>
207
+ <folder id="1">
208
+ <folder .../>
209
+ <folder ...>
210
+ <folder .../>
211
+ </folder>
212
+ <folder .../>
213
+ </folder>
214
+ </refresh>]
215
+ [<notify seq="sequence-number">
216
+ <deleted ids="665,66,452,883"/>
217
+ <created>
218
+ <tag id="66" name="phlox" u="8"/>
219
+ <folder id="4353" name="a&p" u="2" l="1"/>
220
+ </created>
221
+ <modified>
222
+ <tag id="65" u="0"/>
223
+ <m id="553" t="ua"/>
224
+ </modified>
225
+ </notify>]+
226
+ </context>
227
+ <soap:/Header>]
228
+ <soap:Body>
229
+ <BatchResponse xmlns="urn:zimbra">
230
+ <soap:Fault requestId="1">
231
+ </soap:Fault>
232
+ <BarResponse ... requestId="2">
233
+ </BarResponse>
234
+ </BatchResponse>
235
+ </soap:Body>
236
+ </soap:Envelope>
237
+
238
+ User Agent
239
+
240
+ userAgent is an optional context element that is used for identifying the
241
+ type of SOAP client that's making the request. The user agent is written
242
+ to mailbox.log messages with the context string "ua".
243
+
244
+ Request and Response Formats
245
+
246
+ The requests and responses can be specified in XML or JSON format. The
247
+ server determines the request format automatically but JSON requests
248
+ MUST follow these requirements:
249
+
250
+ * request encoded in UTF-8
251
+ * start with '{' for server to identify JSON content
252
+ * do not include "Envelope" object
253
+ * elements specified as "name": { ... }
254
+ * attributes specified as "name": "value"
255
+ * namespace attribute specified as "_jsns": "ns-uri"
256
+ * element text content specified as "_content": "content"
257
+ * element list specified as "name": [ ... ]
258
+
259
+ Example:
260
+
261
+ {
262
+ "Header": {
263
+ "context": {
264
+ "_jsns": "urn:zimbra",
265
+ "authToken": {
266
+ "_content": "0_3e761bdc...303b"
267
+ }
268
+ }
269
+ },
270
+ "Body": {
271
+ "FooRequest": {
272
+ "_jsns": "urn:zimbra",
273
+ "name": "attribute content",
274
+ "_content": "element content"
275
+ }
276
+ }
277
+ }
278
+
279
+ The response format is the same as the request format by default.
280
+ To change, specify a "format" element in the request's Header element
281
+ with a "type" attribute. The value must be either "xml" or "js".
282
+
283
+ SOAP request with JSON response:
284
+
285
+ <soap:Envelope ...>
286
+ <soap:Header>
287
+ <context xmlns="urn:zimbra">
288
+ ...
289
+ <format type='js' />
290
+ </context>
291
+ </soap:Header>
292
+ ...
293
+ </soap:Envelope>
294
+
295
+ JSON request with XML response:
296
+
297
+ {
298
+ "Header": {
299
+ "context": {
300
+ ...
301
+ "format": { "type": "xml" },
302
+ "_jsns": "urn:zimbra"
303
+ }
304
+ },
305
+ ...
306
+ }
307
+
308
+ -----------------------------
309
+
310
+ SOAP 1.2
311
+
312
+ <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
313
+ <soap:Body>
314
+ <soap:Fault>
315
+ <soap:Code>
316
+ <soap:Value>soap:Sender</soap:Value>
317
+ </soap:Code>
318
+ <soap:Reason><soap:Text>...</soap:Text><soap:Reason>
319
+ <soap:Detail>
320
+ <Error xmlns="urn:zimbra">
321
+ <Code>...</Code>
322
+ [<a n="name">VALUE</a>]* // error information (arguments, e.g. ID that was bad, or whatever)
323
+ </Error>
324
+ </soap:Detail>
325
+ </soap:Fault>
326
+ </soap:Body>
327
+ </soap:Envelope>
328
+
329
+ SOAP 1.1
330
+
331
+ <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
332
+ <soap:Body>
333
+ <soap:Fault>
334
+ <soap:faultcode>soap:Server</soap:faultcode>
335
+ <soap:faultstring>Server Error</soap:faultstring>
336
+ <soap:detail>
337
+ <Error xmlns="urn:zimbra">
338
+ <Code>...</Code>
339
+ [<a n="name">VALUE</a>]* // error information (arguments, e.g. ID that was bad, or whatever)
340
+ </Error>
341
+ </soap:detail>
342
+ </soap:Fault>
343
+ </soap:Body>
344
+ </soapEnvelope>
345
+
346
+ global soap/system errors used with zimbra:Error/Code:
347
+
348
+ service.FAILURE - generic system failure
349
+ service.INVALID_REQUEST - bad request (missing args, etc)
350
+ service.UNKNOWN_DOCUMENT - no handler for specified document
351
+ service.PARSE_ERROR - XML parsing error
352
+ service.PERM_DENIED - permission denied
353
+ service.AUTH_REQUIRED - an authtoken is required
354
+ service.AUTH_EXPIRED - authentication creds have expired
355
+ service.WRONG_HOST - operation is sent to a wrong host
356
+ service.PROXY_ERROR - unable to proxy operation
357
+ service.TOO_MANY_HOPS - operation was proxied too many times
358
+ service.INTERRUPTED - index operation was interrupted
359
+ service.NOT_IN_PROGRESS - attempt to stop index operation when it was not in progress
360
+ service.ALREADY_IN_PROGRESS - attempt to start index operation when it was already in progress
361
+ service.NO_SPELL_CHECK_URL - spellcheck is not available
362
+ service.RESOURCE_UNREACHABLE - unable to reach the remote resource
363
+ service.TEMPORARILY_UNAVAILABLE - resource is temporarily unavailable
364
+ service.NON_READONLY_OPERATION_DENIED -
365
+
366
+ -----------------------------
367
+ urn:zimbraAccount
368
+
369
+ account error/codes: (includes service.*):
370
+
371
+ account.AUTH_FAILED - bad account/password
372
+ account.CHANGE_PASSWORD - password must be changed
373
+ account.PASSWORD_LOCKED - password can't be changed
374
+ account.PASSWORD_CHANGE_TOO_SOON = password can't be changed yet
375
+ account.PASSWORD_RECENTLY_USED = can't use the same password again
376
+ account.INVALID_PASSWORD - new password does not meet the system's rules (length, content, etc.)
377
+ account.INVALID_ATTR_NAME - the specified attribute name is invalid
378
+ account.INVALID_ATTR_VALUE - the specified attribute value is invalid
379
+ account.MULTIPLE_ACCOUNTS_MATCHED - when auth by foreignPrincipal matches multiple accounts with the same foreignPrincipal
380
+ account.NO_SUCH_ACCOUNT
381
+ account.NO_SUCH_ALIAS
382
+ account.NO_SUCH_DOMAIN
383
+ account.NO_SUCH_COS
384
+ account.NO_SUCH_IDENTITY
385
+ account.NO_SUCH_SIGNATURE
386
+ account.NO_SUCH_DATA_SOURCE
387
+ account.NO_SUCH_SERVER
388
+ account.NO_SUCH_ZIMLET
389
+ account.NO_SUCH_DISTRIBUTION_LIST
390
+ account.NO_SUCH_CALENDAR_RESOURCE
391
+ account.NO_SUCH_MEMBER
392
+ account.MEMBER_EXISTS
393
+ account.ACCOUNT_EXISTS
394
+ account.DOMAIN_EXISTS
395
+ account.COS_EXISTS
396
+ account.SERVER_EXISTS
397
+ account.DISTRIBUTION_LIST_EXISTS
398
+ account.IDENTITY_EXISTS
399
+ account.SIGNATURE_EXISTS
400
+ account.DATA_SOURCE_EXISTS
401
+ account.DOMAIN_NOT_EMPTY
402
+ account.MAINTENANCE_MODE
403
+ account.ACCOUNT_INACTIVE
404
+ account.TOO_MANY_ACCOUNTS
405
+ account.TOO_MANY_IDENTITIES
406
+ account.TOO_MANY_SIGNATURES
407
+ account.TOO_MANY_DATA_SOURCES
408
+ account.TOO_MANY_SEARCH_RESULTS
409
+
410
+ <AuthRequest xmlns="urn:zimbraAccount">
411
+ [<account by="name|id|foreignPrincipal">...</account>]
412
+ [<password>...</password>]
413
+ [<preauth timestamp="{timestamp}" expires="{expires}">{computed-preauth-value}</preauth>]
414
+ [<authToken>...</authToken>]
415
+ [<virtualHost>{virtual-host}</virtualHost>]
416
+ [<prefs>[<pref name="..."/>...]</prefs>]
417
+ [<attrs>[<attr name="..."/>...]</attrs>]
418
+ [<requestedSkin>{skin}</requestedSkin>]
419
+ </AuthRequest>
420
+
421
+ <AuthResponse">
422
+ <authToken>...</authToken>
423
+ <lifetime>...</lifetime>
424
+ <session .../>
425
+ <refer>{mail-host}</refer>
426
+ [<prefs><pref name="{name}" modified="{modified-time}">{value}</pref>...</prefs>]
427
+ [<attrs><attr name="{name}">{value}</attr>...</attrs>]
428
+ [<skin>{skin-name}</skin>]
429
+ </AuthResponse>
430
+
431
+ Note:
432
+
433
+ when specifiying an account, one of <password> or <preauth> must be specified. see preauth.txt for a discussion of preauth.
434
+
435
+ an authToken can be passed instead of account/password/preauth to validate an existing auth token.
436
+
437
+ {mail-host} = host additional SOAP requests should be directed to. Always returned, might be same as original host request was sent to.
438
+
439
+ {virtual-host} = if specified (in conjunction with by="name"), virtual-host is used to determine the domain of the account name, if it
440
+ does not include a domain component. For example, if the domain foo.com has a zimbraVirtualHostname of "mail.foo.com",
441
+ and an auth request comes in for "joe" with a virtualHost of "mail.foo.com", then the request will be equivalent to
442
+ logging in with "joe@foo.com".
443
+
444
+ only attrs that are allowed to be returned by GetInfo will be returned by this call
445
+
446
+ {requested-skin} = if specified the name of the skin requested by client
447
+
448
+ {skin-name} = if requested-skin specified, the name of the skin to use
449
+
450
+ ---------
451
+
452
+ <ChangePasswordRequest>
453
+ <account by="name">...</account>
454
+ <oldPassword>...</oldPassword>
455
+ <password>...</password>
456
+ [<virtualHost>{virtual-host}</virtualHost>]
457
+ </ChangePasswordRequest>
458
+
459
+ <ChangePasswordResponse>
460
+ <authToken>...</authToken>
461
+ <lifetime>...</lifetime>
462
+ <ChangePasswordResponse/>
463
+
464
+ {virtual-host} = if specified virtual-host is used to determine the domain of the account name, if it
465
+ does not include a domain component. For example, if the domain foo.com has a zimbraVirtualHostname of "mail.foo.com",
466
+ and an auth request comes in for "joe" with a virtualHost of "mail.foo.com", then the request will be equivalent to
467
+ logging in with "joe@foo.com".
468
+
469
+ Returns new authToken, as old authToken will be invalidated on password change.
470
+
471
+ ---------------------------
472
+
473
+ <EndSessionRequest xmlns="urn:zimbraAccount"/>
474
+
475
+ Ends the current session, removing it from all caches. Called when
476
+ the browser app (or other session-using app) shuts down. Has no
477
+ effect if called in a <nosession> context.
478
+
479
+ ---------
480
+ <GetPrefsRequest>
481
+ <!-- get only the specified prefs -->
482
+ [<pref name="{name1}"/>
483
+ <pref name="{name2}"/>]
484
+ </GetPrefsRequest>
485
+
486
+ If no <pref> elements are provided, all known prefs are returned in the response.
487
+ If <pref> elements are provided, only those prefs are returned in the response.
488
+
489
+ <GetPrefsResponse>
490
+ <pref name="{name}">{value}</pref>
491
+ ...
492
+ <pref name="{name}">{value}</pref>
493
+ </GetPrefsResponse>
494
+
495
+ ----------------------------
496
+
497
+ <GetInfoRequest [sections="mbox,prefs,attrs,zimlets,props,idents,sigs,dsrcs,children"]>
498
+ </GetInfoRequest>
499
+
500
+ <-- by default, GetInfo returns all data; to limit the returned data, specify only the sections you want in the "sections" attr -->
501
+
502
+ <GetInfoResponse>
503
+ <version>{version}</version>
504
+ <id>{account-id}</id>
505
+ <name>{account-name}</name>
506
+ <lifetime>...</lifetime>
507
+ [<adminDelegated>{admin-delegated}</adminDelegated>
508
+ <rest>{account-base-REST-url}</rest>
509
+ <used>{used}</used>
510
+ <prevSession>{previous-SOAP-session}</prevSession>
511
+ <accessed>{last-SOAP-access}</accessed>
512
+ <recent>{recent-messages}</recent>
513
+ ]
514
+ <docSizeLimit>{document-size-limit}</docSizeLimit>
515
+ <attSizeLimit>{attachment-size-limit}</attSizeLimit>
516
+ <cos name="cos-name" id="cos-id"/>
517
+ <attrs>
518
+ <attr name="{name}">{value}</a>
519
+ ...
520
+ <attr name="{name}">{value}</a>
521
+ </attrs>
522
+ <prefs>
523
+ <pref name="{name}">{value}</pref>
524
+ ...
525
+ <pref name="{name}">{value}</pref>
526
+ </prefs>
527
+ <props>
528
+ <prop zimlet="{zimlet-name}" name="{name}">{value}</prop>
529
+ ...
530
+ <prop zimlet="{zimlet-name}" name="{name}">{value}</prop>
531
+ </props>
532
+ <zimlets>
533
+ <zimlet>
534
+ <zimletContext baseUrl="..." priority="..." presence="{zimlet-presence}"/>
535
+ <zimlet>...</zimlet>
536
+ <zimletConfig>...</zimletConfig>
537
+ </zimlet>
538
+ ...
539
+ </zimlets>
540
+ <mailURL>{mail-url}</mailURL>+
541
+ <publicURL>{account-base-public-url}</publicURL>
542
+ <identities>
543
+ <identity name={identity-name} id="...">
544
+ <a name="{name}">{value}</a>
545
+ ...
546
+ <a name="{name}">{value}</a>
547
+ </identity>*
548
+ </identities>
549
+ <signatures>
550
+ <signature name={signature-name} id="...">
551
+ <a name="{name}">{value}</a>
552
+ ...
553
+ <a name="{name}">{value}</a>
554
+ </signature>*
555
+ </signatures>
556
+ <dataSources>
557
+ {data-source}
558
+ ...
559
+ </dataSources>*
560
+ <childAccounts>
561
+ <childAccount name="{child-account-name}" visible="0|1" id="{child-account-id}">
562
+ <attrs>
563
+ <attr name="{name}">{value}</a>*
564
+ </attrs>
565
+ </childAccount>*
566
+ </childAccounts>
567
+ </GetInfoResponse>
568
+
569
+ {version} = server version: <major>[.<minor>[.<maintenance>]][build] <release> <date>[ <type>]
570
+ {account-name} = email address (user@domain)
571
+ {life-time} = number of milliseconds until auth token expires
572
+ {admin-delegated} = "1" if the auth token is a delegated auth token issued to an admin account
573
+ {account-base-REST-url} = base REST URL for the requested account
574
+
575
+
576
+
577
+ returned only if the command successfully executes on the target user's home mail server:
578
+ {used} = mailbox quota used in bytes
579
+ {last-SOAP-access} = time (in millis) of last write op from this session, or from *any* SOAP session if we don't have one
580
+ {previous-SOAP-session} = time (in millis) of last write op from any SOAP session before this session was initiated,
581
+ or same as {last-SOAP-access} if we don't have one
582
+ {recent-messages} = number of messages received since the previous soap session, or since the last SOAP write op if we don't have a session
583
+
584
+ prefs = user-settable preferences
585
+ attrs = account attrs that aren't user-settable, but the front-end needs.
586
+ Only attributes listed in zimbraAccountClientAttrs will be returned.
587
+
588
+ {mail-url} = URL to talk to for soap service for this account. i.e:
589
+
590
+ http://server:7070/service/soap/
591
+
592
+ Multiple URLs can be returned if both http and https (SSL) are enabled. If only one of the two is enabled,
593
+ the only one URL will be returned.
594
+
595
+ {account-base-public-url} = base public URL for the requested account
596
+
597
+ attrs under <childAccount>: including the following attrs of the child account:
598
+ - displayName
599
+
600
+ {data-source}: see GetDataSourcesRequest for details
601
+
602
+ {zimlet-presence}: mandatory | enabled | disabled
603
+
604
+ ----------------------------
605
+
606
+ <GetAccountInfoRequest>
607
+ <account by="id|name">...</account>
608
+ </GetAccountInfoRequest>
609
+
610
+ <GetAccountInfoResponse>
611
+ <name>{account-name}</name>
612
+ <attr name="{name}">{value}</a>+
613
+ <soapURL>{mail-url}</soapURL>+
614
+ <publicURL>{account-base-public-url}</publicURL>
615
+ </GetAccountInfoResponse>
616
+
617
+ {account-name} = email address (user@domain)
618
+
619
+ {attrs} = account attrs. Currently only two attrs are returned:
620
+
621
+ zimbraId - the unique UUID of the zimbra account
622
+ zimbraMailHost - the server on which this user's mail resides
623
+
624
+ {mail-url} = URL to talk to for soap service for this account. i.e:
625
+
626
+ http://server:7070/service/soap/
627
+
628
+ Multiple URLs can be returned if both http and https (SSL) are enabled. If only one of the two is enabled,
629
+ the only one URL will be returned.
630
+
631
+ {account-base-public-url} = base public URL for the requested account
632
+
633
+ ----------------------------
634
+
635
+ <GetAvailableSkinsRequest/>
636
+
637
+ <GetAvailableSkinsResponse>
638
+ <skin name="{skin-name}"/>+
639
+ </GetAvailableSkinsResponse>
640
+
641
+ Returns intersection of installed skins on the server and the list
642
+ specified in the zimbraAvailableSkin on an account (or its
643
+ CoS). If none is set in zimbraAvailableSkin, it returns the
644
+ entire list of installed skins. The installed skin list is obtained
645
+ by a directory scan of the designated location of skins on a server.
646
+
647
+ ----------------------------
648
+
649
+ <GetAvailableCsvFormatsRequest/>
650
+
651
+ <GetAvailableCsvFormatsResponse>
652
+ <csv name="{format-name}"/>+
653
+ </GetAvailableCsvFormatsResponse>
654
+
655
+ Returns the known CSV formats that can be used for
656
+ import and export of addressbook.
657
+
658
+ ----------------------------
659
+
660
+
661
+ <SearchGalRequest [type="{type}"] [limit="..."] [offset="..."] [sortBy="{sort-by}"] [groupBy="{group-by}"] [needExp="1|0"]>
662
+ [<cursor id="{prevId}" sortVal="{prevSortValue}" endSortVal="{endSortValue}"/> ]
663
+ <name>...</name>
664
+
665
+ [<searchFilter>
666
+ <conds [not="1|0"] [or="1|0"] >
667
+ [<cond> or <conds>]+
668
+ </conds> (exactly one instance of <conds>)
669
+
670
+ -- or --
671
+
672
+ <cond [not="1|0"] attr="{attr}" op="{op}" value="{value}" /> (exactly one instance of <cond>)
673
+ </searchFilter>]
674
+
675
+ </SearchGalRequest>
676
+
677
+ <SearchGalResponse more="{more}" sortBy="sort-by" offset="..." [tokenizeKey="{tokenize-key-op}"]>
678
+ <cn [exp="1|0"]>
679
+ <a n="...">...</a>+
680
+ </cn>*
681
+ </SearchGalResponse>
682
+
683
+ {more-flag} = 1 if the results were truncated.
684
+
685
+ {tokenize-key-op} = and|or
686
+ - Not present if the search key was not tokenized.
687
+ - Some clients backtrack on GAL results assuming the results of a more
688
+ specific key is the subset of a more generic key, and it checks cached
689
+ results instead of issuing another SOAP request to the server.
690
+ If search key was tokenized and expanded with AND or OR, this cannot
691
+ be assumed.
692
+
693
+ {type} = type of addresses to search
694
+ "account" for regular user accounts, aliases and distribution lists
695
+ "resource" for calendar resources
696
+ "all" for combination of both types
697
+ if omitted, defaults to "all"
698
+
699
+ needExp: if the "exp" flag is needed in the response for group entries.
700
+ default is 0
701
+
702
+ exp: if the user can (has right to) expand group members
703
+ returned only if needExp is 1 in the request and only on group entries (type=group in attrs on a <cn>).
704
+
705
+ see SearchRequest for use of cursor.
706
+
707
+ see SearchCalendarResources for use of searchFilter
708
+
709
+ ----------------------------
710
+
711
+ <AutoCompleteGalRequest [type="{type}"] [needExp="1|0"]>
712
+ <name>...</name>
713
+ </AutoCompleteGalRequest>
714
+
715
+ <AutoCompleteGalResponse more="{more}" [tokenizeKey="{tokenize-key-op}"]>
716
+ <cn [exp="1|0"]>
717
+ <a n="...">...</a>+
718
+ </cn>*
719
+ </AutoCompleteGalResponse>
720
+
721
+ - the number of entries in the response is limited by Account/COS attribute
722
+ zimbraContactAutoCompleteMaxResults with default value of 20.
723
+
724
+ {type} = type of addresses to auto-complete on
725
+ "account" for regular user accounts, aliases and distribution lists
726
+ "resource" for calendar resources
727
+ "all" for combination of both types
728
+ if omitted, defaults to "accounts"
729
+
730
+ {more-flag} = 1 if the results were truncated.
731
+
732
+ {tokenize-key-op} = and|or
733
+ - Not present if the search key was not tokenized.
734
+ - Some clients backtrack on GAL results assuming the results of a more
735
+ specific key is the subset of a more generic key, and it checks cached
736
+ results instead of issuing another SOAP request to the server.
737
+ If search key was tokenized and expanded with AND or OR, this cannot
738
+ be assumed.
739
+
740
+ needExp: if the "exp" flag is needed in the response for group entries.
741
+ default is 0
742
+
743
+ exp: if the user can (has right to) expand group members
744
+ returned only if needExp is 1 in the request and only on group entries (type=group in attrs on a <cn>).
745
+
746
+ ----------------------------
747
+
748
+ <AutoCompleteRequest [folders="{folders}"] [includeGal="0|1"] [needExp="1|0"]>
749
+ <name>...</name>
750
+ </AutoCompleteRequest>
751
+
752
+ <AutoCompleteResponse canBeCached="0|1">
753
+ <match ranking="..." email="..." type="gal|contact|rankingTable" isGroup="1|0" [exp="1|0"] [display="..."] [id="..."] [l="..."] />*
754
+ </AutoCompleteResponse>
755
+
756
+ {folders} - comma separates list of folder IDs.
757
+
758
+ - the number of entries in the response is limited by Account/COS attribute
759
+ zimbraContactAutoCompleteMaxResults with default value of 20.
760
+ - email field contains comma separated email addresses in case of group
761
+ - display field contains string that should be displayed by the client
762
+ - isGroup: if the entry is a group
763
+ - needExp: if the "exp" flag is needed in the response for group entries.
764
+ default is 0
765
+ - exp: if the user can (has right to) expand group members
766
+ returned only if needExp is 1 in the request and only on group entries (isGroup=1).
767
+
768
+ ----------------------------
769
+
770
+ <SyncGalRequest [token="{previous-token}] [idOnly={true|false}]"/>
771
+
772
+ <SyncGalResponse token="{new-token}">
773
+ <cn>...</cn>*
774
+ <deleted id="{itemId}">*
775
+ </SyncGalResponse>
776
+
777
+ If the request has idOnly set to true, then the response will contain
778
+ id attribute without all the contact fields populated. The sync client
779
+ then should make batch request to the server to fetch the contact fields
780
+ with <GetContactsRequest/>.
781
+ Note: idOnly only works when GAL sync account is configured/enabled.
782
+ If idOnly is specified and GAL sync account is not enabled, idOnly will
783
+ be ignored.
784
+
785
+ ----------------------------
786
+
787
+ <SearchCalendarResourcesRequest>
788
+ [attrs="a1,a2,a3"] [sortBy="{sortBy}"] [sortAscending="{sortAscending}"] [limit="..."] [offset="..."]>
789
+
790
+ [<name>...</name>]
791
+ <searchFilter>
792
+ <conds [not="1|0"] [or="1|0"] >
793
+ [<cond> or <conds>]+
794
+ </conds> (exactly one instance of <conds>)
795
+
796
+ -- or --
797
+
798
+ <cond [not="1|0"] attr="{attr}" op="{op}" value="{value}" /> (exactly one instance of <cond>)
799
+ </searchFilter>
800
+
801
+ </SearchCalendarResourcesRequest>
802
+
803
+ <SearchCalendarResourcesResponse [paginationSupported="1|0"]>
804
+ <calresource name="{name}" id="{id}">
805
+ <a n="...">...</a>+
806
+ </calresource>*
807
+ </SearchCalendarResourcesResponse>
808
+
809
+ Notes:
810
+ SearchCalendarResourcesRequest:
811
+ attrs - comma-seperated list of attrs to return ("displayName", "zimbraId", "zimbraCalResType")
812
+ sortBy - name of attribute to sort on. default is the calendar resource name.
813
+ sortAscending - whether to sort in ascending order (0/1), 1 is default
814
+
815
+ name: if specified, pass through to the GAL search as the search key
816
+
817
+ must have exactly one <conds> child or exactly one <cond> child and no other child element
818
+
819
+ conds: denotes a compound condition
820
+ must have 1 or more children
821
+ each child can be a <cond> or <conds>
822
+ not - if 1, negate the compound condition
823
+ or - if 1, child conditions are OR'd together; if 0 (default), they are AND'ed together
824
+
825
+ cond: denotes a simple condition of "attr operator value" form
826
+ not - if 1, negate the condition
827
+ attr - attribute name
828
+ op - operator; valid operators are:
829
+ "eq" - attr equals value (integer or string)
830
+ "has" - attr has value (substring search)
831
+ "ge" - attr greater than or equal to integer value
832
+ "le" - attr less than or equal to integer value
833
+ "gt" - attr greater than (but not equal to) integer value
834
+ "lt" - attr less than (but not equal to) integer value
835
+ "startswith" - attr starts with value (string)
836
+ "endswith" - attr ends with value (string)
837
+ value - value
838
+
839
+ SearchCalendarResourcesResponse:
840
+ paginationSupported:
841
+ 1 - limit and offset in the request was honored
842
+ 0 - the underlying search does not support pagination
843
+ limit and offset in the request was not honored
844
+
845
+
846
+ ----------------------------
847
+
848
+ <ModifyPrefsRequest>
849
+ [<pref name="{name}">{value}</pref>...]+
850
+ </ModifyPrefsRequest>
851
+
852
+ <ModifyPrefsResponse/>
853
+
854
+ Notes:
855
+ For multi-value prefs, just add the same attribute with 'n' different values:
856
+ <ModifyPrefsRequest>
857
+ <pref name="foo">value1</pref>
858
+ <pref name="foo">value2</pref>
859
+ .
860
+ .
861
+ .
862
+ </ModifyPrefsRequest>
863
+
864
+ You can also add/subtract single values to/from a multi-value pref by prefixing
865
+ the preference name with a '+' or '-', respectively in the same way you do when
866
+ using zmprov. For example:
867
+ <ModifyPrefsRequest>
868
+ <pref name="+foo">value1</pref>
869
+ <pref name="-foo">value2</pref>
870
+ .
871
+ .
872
+ .
873
+ </ModifyPrefsRequest>
874
+
875
+ ---------
876
+
877
+ <CreateIdentityRequest>
878
+ <identity name="{identity-name}">
879
+ <a name="{name}">{value}</a>
880
+ ...
881
+ <a name="{name}">{value}</a>
882
+ </identity>
883
+ </CreateIdentityRequest>
884
+
885
+ <CreateIdentityResponse>
886
+ <identity name="{identity-name}" id="{identity-id}">
887
+ ....
888
+ </identity>
889
+ </CreateIdentityResponse>
890
+
891
+
892
+ Allowed attributes (see objectclass zimbraIdentity in zimbra.schema)
893
+
894
+ zimbraPrefBccAddress
895
+ zimbraPrefForwardIncludeOriginalText
896
+ zimbraPrefForwardReplyFormat
897
+ zimbraPrefForwardReplyPrefixChar
898
+ zimbraPrefFromAddress
899
+ zimbraPrefFromDisplay
900
+ zimbraPrefMailSignature
901
+ zimbraPrefMailSignatureEnabled
902
+ zimbraPrefMailSignatureStyle
903
+ zimbraPrefReplyIncludeOriginalText
904
+ zimbraPrefReplyToAddress
905
+ zimbraPrefReplyToDisplay
906
+ zimbraPrefReplyToEnabled
907
+ zimbraPrefSaveToSent
908
+ zimbraPrefSentMailFolder
909
+ zimbraPrefUseDefaultIdentitySettings
910
+ zimbraPrefWhenInFolderIds
911
+ zimbraPrefWhenInFoldersEnabled
912
+ zimbraPrefWhenSentToAddresses
913
+ zimbraPrefWhenSentToEnabled
914
+
915
+
916
+ ---------
917
+
918
+ <GetIdentitiesRequest/>
919
+
920
+ <GetIdentitiesResponse>
921
+ <identity name="{identity-name}" id="{identity-id}">
922
+ <a name="{name}">{value}</a>
923
+ ...
924
+ <a name="{name}">{value}</a>
925
+ </identity>+
926
+ </GetIdentitiesResponse>
927
+
928
+ ---------
929
+
930
+ <ModifyIdentityRequest>
931
+ <identity [name="{identity-name}" | id="{identity-id}"]>
932
+ <a name="{name}">{value}</a>
933
+ ...
934
+ <a name="{name}">{value}</a>
935
+ </identity>
936
+ </ModifyIdentityRequest>
937
+
938
+ <ModifyIdentityResponse/>
939
+
940
+ <-- must specify either 'name' or 'id' -->
941
+
942
+ ---------
943
+
944
+ <DeleteIdentityRequest>
945
+ <identity [name="{identity-name}" | id="{identity-id}"]/>
946
+ </DeleteIdentityRequest>
947
+
948
+ <DeleteIdentityResponse/>
949
+
950
+ <-- must specify either 'name' or 'id' -->
951
+
952
+ ---------
953
+
954
+ <CreateSignatureRequest>
955
+ <signature name="{signature-name}" [id="{id}"]/>
956
+ <content type="{text/plain | text/html}">{signature-value}</content>+
957
+ [<cid>{contact-id}</cid>]
958
+ </signature>
959
+ </CreateSignatureRequest>
960
+
961
+ <CreateSignatureResponse>
962
+ <signature id="{id}" name="{signature-name}"/>
963
+ </CreateSignatureResponse>
964
+
965
+ - If an id is provided it will be honored as the id for the signature.
966
+
967
+ - CreateSignature will set account default signature to the signature being created
968
+ if there is currently no default signature for the account.
969
+
970
+ - There can be at most one text/plain signatue and one text/html signature.
971
+
972
+ - {contact-id} contact id associated with this signature
973
+
974
+ ---------
975
+
976
+ <GetSignaturesRequest/>
977
+
978
+ <GetSignaturesResponse>
979
+ <signature name="{signature-name}" id="{signature-id}"
980
+ <content type="{text/plain | text/html}">{signature-value}</content>+
981
+ [<cid>{contact-id}</cid>]
982
+ </signature>+
983
+ </GetSignaturesResponse>
984
+
985
+ ---------
986
+
987
+ <ModifySignatureRequest>
988
+ <signature id="{signature-id}" [name="{signature-name}"]>
989
+ <content type="{text/plain | text/html}">{signature-value}</content>+
990
+ [<cid>{contact-id}</cid>]
991
+ </signature>
992
+ </ModifySignatureRequest>
993
+
994
+ <ModifySignatureResponse/>
995
+
996
+ - Changes attributes of the given signature. Only the attributes specified in the request
997
+ are modified.
998
+
999
+ - Server identify the signature by id, if the name attribute is present and is different
1000
+ from the current name of the signature, the signature will be renamed.
1001
+
1002
+ ---------
1003
+
1004
+ <DeleteSignatureRequest>
1005
+ <signature [name="{signature-name}" | id="{signature-id}"]/>
1006
+ </DeleteSignatureRequest>
1007
+
1008
+ <DeleteSignatureResponse/>
1009
+
1010
+ <-- must specify either 'name' or 'id' -->
1011
+
1012
+ ---------
1013
+
1014
+ urn:zimbraMail
1015
+
1016
+ mail error/codes: (includes service.*)
1017
+
1018
+ Error code parameters:
1019
+ - Error results have data parameters encoded in the
1020
+ soap:detail for the error, in <a> elements:
1021
+
1022
+ [<a n="name">VALUE</a>]* // error information (arguments,
1023
+ e.g. ID that was bad, or whatever)
1024
+
1025
+ - See SOAP 1.1 or SOAP 1.2 section above.
1026
+
1027
+ List of error codes:
1028
+ mail.MAINTENANCE - in maintenance
1029
+ mail.NO_SUCH_MBOX - no such mailbox
1030
+ mail.NO_SUCH_ITEM - no such item
1031
+ mail.NO_SUCH_CONV - no such converstation
1032
+ mail.NO_SUCH_MSG - no such message
1033
+ mail.NO_SUCH_PART - no such message part
1034
+ mail.NO_SUCH_FOLDER - no such folder
1035
+ mail.NO_SUCH_TAG - no such tag
1036
+ mail.NO_SUCH_CONTACT - no such contact
1037
+ mail.NO_SUCH_CALITEM - no such calendar item
1038
+ mail.NO_SUCH_APPT - no such appointment
1039
+ mail.NO_SUCH_TASK - no such task
1040
+ mail.NO_SUCH_DOC - no such doc
1041
+ mail.NO_SUCH_UPLOAD - no such upload
1042
+ mail.NO_SUCH_WAITSET - no such waitset
1043
+ mail.QUERY_PARSE_ERROR - couldn't parse search query (see below
1044
+ for detailed error info)
1045
+ mail.NO_SUCH_CONTACT - the specified contact id did not exist
1046
+ mail.MODIFY_CONFLICT - if the modified date on a contact is different then one in the request
1047
+ mail.ALREADY_EXISTS
1048
+ mail.INVALID_ID
1049
+ mail.INVALID_SYNC_TOKEN
1050
+ mail.INVALID_NAME
1051
+ mail.INVALID_TYPE
1052
+ mail.INVALID_CONTENT_TYPE
1053
+ mail.IS_NOT_CHILD
1054
+ mail.CANNOT_CONTAIN
1055
+ mail.CANNOT_COPY
1056
+ mail.CANNT_TAG
1057
+ mail.CANNOT_PARENT
1058
+ mail.CANNOT_RENAME
1059
+ mail.CANNOT_SUBSCRIBE
1060
+ mail.IMMUTABLE_OBJECT
1061
+ mail.WRONG_MAILBOX
1062
+ mail.MODIFY_CONFLICT
1063
+ mail.TRY_AGAIN
1064
+ mail.SCAN_ERROR
1065
+ mail.UPLOAD_REJECTED
1066
+ mail.TOO_MANY_TAGS
1067
+ mail.TOO_MANY_UPLOADS
1068
+ mail.TOO_MANY_CONTACTS
1069
+ mail.UNABLE_TO_IMPORT_CONTACTS
1070
+ mail.UNABLE_TO_IMPORT_APPOINTMENTS
1071
+ mail.QUOTA_EXCEEDED
1072
+ mail.QUERY_PARSE_ERROR
1073
+ mail.MESSAGE_PARSE_ERROR
1074
+ mail.ADDRESS_PARSE_ERROR
1075
+ mail.ICALENDAR_PARSE_ERROR
1076
+ mail.MUST_BE_ORGANIZER
1077
+ mail.CANNOT_CANCEL_INSTANCE_OF_EXCEPTION
1078
+ mail.INVITE_OUT_OF_DATE
1079
+ mail.SEND_ABORTED_ADDRESS_FAILURE
1080
+ mail.SEND_PARTIAL_ADDRESS_FAILURE
1081
+ mail.SEND_FAILURE
1082
+ mail.TOO_MANY_QUERY_TERMS_EXPANDED
1083
+ mail.INVALID_COMMIT_ID
1084
+
1085
+
1086
+
1087
+ ------------------------------
1088
+
1089
+ mail.QUERY_PARSE_ERROR details
1090
+
1091
+ Arguments:
1092
+ colNo - index into query string where the error occured
1093
+ curTok - current token being parsed (not always set)
1094
+ parserErr - localizable error code describing what happened. Current codes:
1095
+ UNKNOWN_TEXT_AFTER_IS - user entered is:blah, blah unknown
1096
+ MISSING_TEXT_AFTER_TOFROMCC - user entered from: without required text
1097
+ LEXICAL_ERROR - Invalid character in search string or invalid operator name (e.g. "iis:foo")
1098
+ PARSER_ERROR - Missing operand after operator ("in:") or other general parse error, look at curTok
1099
+ INVALID_DATE - Couldn't parse argument to date: (before: after: etc) query. Check curTok.
1100
+
1101
+ ------------------------------
1102
+
1103
+ <!--
1104
+
1105
+ defaults aren't normally included in the response, they may
1106
+ be shown here in examples though
1107
+
1108
+ -->
1109
+
1110
+ Email addresses:
1111
+
1112
+ <e [t="{type}"] p="{personal-name}" a="{email-address}" d="{display-name}">{content}</e>
1113
+
1114
+ {type} = (f)rom, (t)o, (c)c, (b)cc, (r)eply-to, (s)ender, read-receipt (n)otification
1115
+
1116
+ Type is only sent when an individual message is returned. In the
1117
+ list of conversations, all the email addresseses returned for a conversation are a subset
1118
+ of the participants. In the list of messages in a converstation, the email addressses are
1119
+ the senders.
1120
+
1121
+ {personal-name} = the comment/name part of an address
1122
+ {email-address} = the user@domain part of an address
1123
+ {display-name} = if we have personal, first word in "word1 word2" format, or last word in "word1, word2" format.
1124
+ if no personal, take string before "@" in email-address.
1125
+ {content} = the original email string as specified by the sender (since we can't reliably reconstruct it
1126
+ out of the components)
1127
+
1128
+ MimeParts:
1129
+
1130
+ <mp part="{mime-part-name}" body="{is-body}" s="{size-in-bytes} mid="{message-id} cid="{conv-id}" [truncated="1"]
1131
+ ct="{content-type}" name="{name}" cd="{content-disposition}" filename="{filename} ci="{content-id} cl="{content-location}">
1132
+ [<content>{content}</content>]
1133
+ <mp part="..." ...>
1134
+ <mp part="..." ...>
1135
+ </mp>
1136
+ </mp>
1137
+ </mp>
1138
+
1139
+ {mime-part-name} = MIME part, "" means top-level part, 1 first part, 1.1 first part of a multipart inside of 1.
1140
+ truncated="1" = the caller requested a maximum length (max="...") for inlined <content>, and this part's content was truncated down to that length
1141
+
1142
+ {content-type} = MIME Content-Type. The mime type is the content of the element.
1143
+ {name} = name attribute from the Content-Type param list
1144
+ {cont-disp} = MIME Content-Disposition
1145
+ {filename} = filename attribute from the Content-Disposition param list
1146
+ {content-id} = MIME Content-ID (for display of embedded images)
1147
+ {content-location} = MIME/Microsoft Content-Location (for display of embedded images)
1148
+ {cont-desc} = MIME Content-Description. Note cont-desc is not currently used in the code.
1149
+ {content} = the content of the part, if requested
1150
+ {is-body} = set to 1, if this part is considered to be the "body" of the message for display
1151
+ purposes.
1152
+ {message-id} = item id of the enclosing message, only present if <mp> is not enclosed within a <m> element
1153
+
1154
+ Messages:
1155
+
1156
+ <m id="{message-id}" f="{flags}" s="{size}" d="{date}" cid="{conv-id}" l="{folder} origid="{original-id}">
1157
+ <content>....</content>*
1158
+ <e .../>*
1159
+ <su>{subject}</su>
1160
+ <fr>{fragment}</fr>
1161
+
1162
+ <mid>{Message-ID header}</mid>
1163
+ [<inv>...</inv>]
1164
+ [<mp>...</mp>]
1165
+ [<content (url="{url}")>...</content>]
1166
+ </m>
1167
+
1168
+ {content} = complete rfc822 message. only present during certain operations that deal with the raw content
1169
+ of a message. There is at most 1 content element.
1170
+ {conv-id} = converstation id. only present if <m> is not enclosed within a <c> element
1171
+ {size} = size in bytes
1172
+ {flags} = (u)nread, (f)lagged, has (a)ttachment, (r)eplied, (s)ent by me, for(w)arded, calendar in(v)ite,
1173
+ (d)raft, IMAP-\Deleted (x), (n)otification sent, urgent (!), low-priority (?)
1174
+ {date} = secs since epoch, from date header in message
1175
+ {original-id} = message id of message being replied to/forwarded (outbound messages only)
1176
+ {url} = content servlet relative url for retrieving message content
1177
+ {subject} = subject of the message, only returned on an expanded message
1178
+ {fragment} = first n-bytes of the message (probably between 40-100)
1179
+ <e .../>* = zero or more addresses in the message, indentified by
1180
+ type (t="f|t|c")
1181
+ <inv ...>...</inv> = Parsed out iCal invite. See soap-calendar.txt
1182
+ <mp ...>...</mp> = The root MIME part of the message. There is exactly 1 MIME part under
1183
+ a message element. The "body" will be tagged with body="1", and the content
1184
+ of the body will also be present
1185
+ <content> = the raw content of the message. cannot have more than one of <mp>, <content> url, and <content> body.
1186
+
1187
+ Conversations:
1188
+
1189
+ <c id="{conv-id}" t="{tags}" n="{num-msgs}" [total="{all-msgs}"] d="{date}" f="{flags}" [elided="1"]>
1190
+ <e ...>*
1191
+ <su>{subject}</su>
1192
+ <fr>{fragment}</fr>
1193
+ <m>...</m>+
1194
+ </c>
1195
+
1196
+ {date} = date (secs since epoch) of most recent message in converstation
1197
+ {tags} = list of tag-ids on conv
1198
+ {flags} = same flags as on <m> ("sarwfdxnu!?"), aggregated from all the conversation's messages
1199
+ {subject} = subject of conversation
1200
+ {fragment} = fragment of most recent msg in converstation
1201
+ {num-msgs} = number of messages in conversation without IMAP \Deleted flag set
1202
+ {all-msgs} = total number of messages in conversation
1203
+
1204
+ <e ...>* = zero or more participants in the converstations;
1205
+ if elided="1", some participants are missing before the first returned <e> element
1206
+ <m>...</m>+ = one or more messages in the conversation. When doing search, the <m> elements returned
1207
+ will only have the "id" attribute, and only messages that matched the search will be included.
1208
+
1209
+ Folders:
1210
+
1211
+ <folder id="{folder-id}" name="{folder-name}" l="{parent-id}" [f="{flags}"] [color="{color}"]
1212
+ u="{unread}" [i4u="{imap-unread}"] n="{msg-count}" [i4n="{imap-count}"] s="{total-size}" [view="{default-type}"]
1213
+ [url="{remote-url}"] [perm="{effective-perms}"] [rest="{rest-url}"]>
1214
+ [<acl> <grant perm="{rights}" gt="{grantee-type}" zid="{zimbra-id}" d="{grantee-name}" [pw="{password-for-guest}"] [key=="{access-key}"]/>* </acl>]
1215
+ </folder>
1216
+
1217
+ {folder-name} = name of folder; max length 128; whitespace is trimmed by server;
1218
+ cannot contain ':', '"', '/', or any character below 0x20
1219
+ {parent-id} = id of parent folder (absent for root folder)
1220
+ {flags} = checked in UI (#), exclude free/(b)usy info, IMAP subscribed (*), does not (i)nherit rights from parent, is a s(y)nc folder with external data source, sync is turned on(~), folder does n(o)t allow inferiors / children
1221
+ {color} = numeric; range 0-127; defaults to 0 if not present; client can display only 0-7
1222
+ {unread} = number of unread messages in folder
1223
+ {imap-unread} = number of unread messages with this tag, *including* those with the IMAP \Deleted flag set
1224
+ {msg-count} = number of non-subfolder items in folder
1225
+ {imap-count} = number of non-subfolder items in folder, *including* those with the IMAP \Deleted flag set
1226
+ {total-size} = total size of all of non-subfolder items in folder
1227
+ {default-type} = (optional) default type for the folder; used by web client to decide which view to use;
1228
+ possible values are the same as <SearchRequest>'s {types}: conversation|message|contact|etc
1229
+ {remote-url} = url (RSS, iCal, etc.) this folder syncs its contents to
1230
+ {rest-url} = url to the folder on rest interface for rest-enabled apps (such as wiki and notebook)
1231
+ {effective-perms} = for remote folders, the access rights the authenticated user has on the folder
1232
+ - will contain the calculated (c)reate folder permission if the user has
1233
+ both (i)nsert and (r)ead access on the folder
1234
+
1235
+ folders can have an optional ACL set on them for sharing. if they do (and the authenticated
1236
+ user has (a)dminister rights on the folder), an <acl> element will be returned containing
1237
+ 1 or more <grant> elements, with the following attributes:
1238
+
1239
+ {rights} = some combination of (r)ead, (w)rite, (i)nsert, (d)elete, (a)dminister, workflow action (x), view (p)rivate, view (f)reebusy
1240
+ {grantee-type} = the type of grantee:
1241
+ "usr",
1242
+ "grp",
1243
+ "dom" (domain),
1244
+ "cos",
1245
+ "all" (all authenticated users), "pub" (public authenticated and unauthenticated access),
1246
+ "guest" (non-Zimbra email address and password),
1247
+ "key" (non-Zimbra email address and access key)
1248
+ {grantee-name} = the display name (*not* the zimbra id) of the principal being granted rights;
1249
+ optional if {grantee-type} is "all"
1250
+ {pw} = optional argument. password when {grantee-type} is "guest"
1251
+ {key} = optional argument. access key when {grantee-type} is "key"
1252
+
1253
+ Mountpoints:
1254
+
1255
+ <link id="{folder-id}" name="{folder-name}" l="{parent-id}" [f="{flags}"] owner="{owner's-display-name}" zid="{owner's-zimbra-id}" rid="{id-of-shared-item}" oname="{owner's-name-for-item}" [color="{color}"] [view="{default-type}"]/>
1256
+
1257
+ {folder-name} = name of folder; max length 128; whitespace is trimmed by server;
1258
+ cannot contain ':', '"', '/', or any character below 0x20
1259
+ {parent-id} = id of parent folder (absent for root folder)
1260
+ {flags} = checked in UI (#), exclude free/(b)usy info, IMAP subscribed (*)
1261
+ {owner's-display-name} = primary email address of the owner of the linked-to resource
1262
+ {owner's-zimbra-id} = Zimbra id (guid) of the owner of the linked-to resource
1263
+ {id-of-shared-item} = item id of the linked-to resource in the remote mailbox
1264
+ {owner's-name-for-item} = The name presently used for the item by the owner
1265
+ {color} = numeric; range 0-127; defaults to 0 if not present; client can display only 0-7
1266
+ {default-type} = (optional) default type for the folder; used by web client to decide which view to use;
1267
+ possible values are the same as <SearchRequest>'s {types}:
1268
+ conversation|message|contact|appointment|task|etc
1269
+
1270
+ Tags:
1271
+
1272
+ <tag id="{tag-id}" name="{tag-name}" [color="{color}"] u="{unread}" [i4u="{imap-unread}"]/>
1273
+
1274
+ {tag-name} = name of tag; max length 128; whitespace is trimmed by server;
1275
+ cannot contain ':', '"', '/', or any character below 0x20;
1276
+ cannot begin with '\' (avoid collsions with IMAP)
1277
+ {color} = numeric; range 0-127; defaults to 0 if not present; client can display only 0-7
1278
+ {unread} = number of unread messages with this tag
1279
+ {imap-unread} = number of unread messages with this tag, *including* those with the IMAP \Deleted flag set
1280
+
1281
+ ----------
1282
+
1283
+ <SearchRequest [limit="..."] [offset="..."] [sortBy="{sort-by}"] [groupBy="{group-by}"]
1284
+ [types="{types}"] [recip="*0|1"] [fetch="1|all|{item-id}"] [read="*0|1"]
1285
+ [max="{max-inlined-length}"] [html="*0|1"] [neuter="0|*1"] [field={default_field}]
1286
+ [calExpandInstStart=TIME_IN_MSEC] [calExpandInstEnd=TIME_IN_MSEC]
1287
+ [allowableTaskStatus="need,inprogress,completed,canceled"]
1288
+ [resultMode="{result-mode}"]
1289
+ [inDumpster="*0|1"]
1290
+ >
1291
+ *(<header n="{header-name}/>)
1292
+ [<cursor id="prevId" sortVal="prevSortValue" endSortVal="endSortValue"/> ]
1293
+ // sortVal should be set to the value of the 'sf' (SortField) attribute of the last
1294
+ // hit on the previous 'page' of search results.
1295
+ // endSortVal is NON-INCLUSIVE and optional (used for ranges)
1296
+
1297
+ [ // OPTIONAL: client timezone identification (necessary to time-correct a user-specified date/time query)
1298
+
1299
+ <tz id="timezonename"/> // References an existing server-known timezone by ID
1300
+
1301
+ OR
1302
+
1303
+ // This format is identical to the one defined in soap-calendar.txt, make sure the documents stay in sync
1304
+ <tz
1305
+ id="timezonename" // this name is ignored by the server, but it must be present
1306
+ stdoff="<minutes>" // offset from UTC in standard time; local = UTC + offset
1307
+ [dayoff="<minutes>"] // offset from UTC in daylight time; present only if DST is used
1308
+ >
1309
+ [ // If daylight savings time is not used, <standard> and <daylight> must be
1310
+ // omitted. If DST is used, both <standard> and <daylight> must be present.
1311
+ <standard // time/rule for transitioning from daylight time to standard time
1312
+ // Either specify week/wkday combo, or mday.
1313
+ [
1314
+ week="<number>" // week number; 1=first, 2=second, 3=third, 4=fourth, -1=last
1315
+ wkday="<number>" // day of week; 1=Sunday, 2=Monday, etc.
1316
+ ]
1317
+ mon="<number>" // month; 1=January, 2=February, etc.
1318
+ [mday="<number>"] // day of month (1..31)
1319
+ hour="<number>" // transition hour (0..23)
1320
+ min="<number>" // transition minute (0..59)
1321
+ sec="<number>" // transition second; 0..59, usually 0
1322
+ />
1323
+ <daylight // time/rule for transitioning from standard time to daylight time
1324
+ [
1325
+ week="<number>"
1326
+ wkday="<number>"
1327
+ ]
1328
+ mon="<number>"
1329
+ [mday="<number>"]
1330
+ hour="<number>"
1331
+ min="<number>"
1332
+ sec="<number>"
1333
+ />
1334
+ ] // optional STANDARD/DAYLIGHT definition
1335
+ ] // optional TIMEZONE specifier
1336
+
1337
+ [ // OPTIONAL: client locale identification
1338
+ <locale>LOCALE-STRING</locale> // Where locale string is of the form LL-CC[-V+] where
1339
+ // LL is two character language code
1340
+ // CC is two character country code
1341
+ // V+ is optional variant identifier string
1342
+ //
1343
+ // ISO Language Codes: http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt
1344
+ // ISO Country Codes: http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
1345
+ //
1346
+ //
1347
+ ]
1348
+
1349
+ <query>{query-string}</query>
1350
+
1351
+ </SearchRequest>
1352
+
1353
+ limit is an integer specifying the maximum number of results to return. if limt <= 0 or limit > 1000 then it defaults to 30.
1354
+ offset is an integer specifying the 0-based offset into the results list to return as
1355
+ the first result for this search operation.
1356
+ For example, limit=10 offset=30 will return the 31st through 40th results inclusive.
1357
+ For a response, the order of the returned results represents the sorted order. There
1358
+ is not a separate index attribute or element.
1359
+
1360
+ if fetch="1" (or fetch="first") is specified, the first hit will be expanded inline (messages only at present)
1361
+ if fetch="{item-id}", only the message with the given {item-id} is expanded inline
1362
+ if fetch="all", all hits are expanded inline
1363
+ + if html="1" is also specified, inlined hits will return HTML parts if available
1364
+ + if read="1" is also specified, inlined hits will be marked as read
1365
+ + if neuter="0" is also specified, images in inlined HTML parts will not be "neutered"
1366
+ + if <header>s are requested, any matching headers are included in inlined message hits
1367
+ + if max="{max-inlined-length}" is specified, inlined body content in limited to the given length;
1368
+ if the part is truncated, truncated="1" is specified on the <mp> in question
1369
+
1370
+ if recip="1" is specified
1371
+ + returned sent messages will contain the set of "To:" recipients instead of the sender
1372
+ + returned conversations whose first hit was sent by the user will contain
1373
+ that hit's "To:" recipients instead of the conversation's sender list
1374
+
1375
+ {group-by} = DEPRECATED. Use TYPES instead.
1376
+ {types} = comma-separated list. Legal values are:
1377
+ conversation|message|contact|appointment|task|wiki|document
1378
+ (default is "conversation")
1379
+
1380
+ **NOTE: only ONE of message, conversation may be set. If
1381
+ both are set, the first is used.
1382
+
1383
+ {sort-by} = default is "dateDesc"
1384
+ Valid choices:
1385
+ dateDesc|dateAsc|subjDesc|subjAsc|nameDesc|nameAsc|none(*)
1386
+ * - If sort-by is "none" then cursors MUST NOT be
1387
+ used, and some searches are impossible
1388
+ (searches that require intersection of complex
1389
+ sub-ops). Server will throw an
1390
+ IllegalArgumentException if the search is
1391
+ invalid.
1392
+
1393
+ ADDITIONAL SORT MODES FOR TASKS: valid only if types="task" (and task alone):
1394
+ taskDueAsc|taskDueDesc|taskStatusAsc|taskStatusDesc|taskPercCompletedAsc|taskPercCompletedDesc
1395
+
1396
+ {more-flag} = 1 if there are more search results remaining.
1397
+ {content-matched} = 1 if the content of the message matched
1398
+ <mp> elements will be set for the first response if fetch=1
1399
+ <hp> elements may be present if any attachments matched
1400
+
1401
+ {field} = by default, text without an operator searches the CONTENT field. By setting the
1402
+ {field} value, you can control the default operator. Specify any of the text operators that are
1403
+ available in query.txt, e.g. 'content:' [the default] or 'subject:', etc. The date operators
1404
+ (date, after, before) and the "item:" operator should not be specified as default fields
1405
+ because of quirks in the search grammar.
1406
+
1407
+ calExpandInstStart and calExpandInstEnd:
1408
+ If these are specified, and the search types include calendar item
1409
+ types (e.g. appointment), then the search results include the
1410
+ instances for calendar items within that range in the form
1411
+ described below.
1412
+
1413
+ ***IMPORTANT NOTE: Calendar Items that have no instances within
1414
+ that range are COMPLETELY EXCLUDED from the results (e.g. not even
1415
+ an <appt> element>. Calendar Items with no data (such as Tasks
1416
+ with no date specified) are included, but with no instance
1417
+ information***
1418
+
1419
+ {result-mode} = Specifies the type of result
1420
+ default is "NORMAL"
1421
+ Valid choices:
1422
+ NORMAL|IDS
1423
+ NORMAL : everything
1424
+ IDS : only IDs
1425
+
1426
+
1427
+ For the optional <cursor> element:
1428
+ -- The required parameters are (prevMailItemId, prevSortValue): these
1429
+ correspond to the last hit on the current page (assuming you're
1430
+ going forward -- if you're backing up then they should be the first
1431
+ hit on the current page)....the server uses those parameters to
1432
+ find the spot in the new results that corresponds to your old
1433
+ position: even if some entries have been removed or added to the
1434
+ search results (e.g. if you are searching is:unread and you read
1435
+ some). The endSortVal paramater tells the cursor where to stop
1436
+ returning values
1437
+ -- Cursors are NOT legal if SortBy="none"
1438
+
1439
+
1440
+ conversation result:
1441
+ --------------------
1442
+
1443
+ <SearchResponse sortBy="sort-by" offset="..." more="{more-flag}">
1444
+ [<info>
1445
+ [<wildcard str="foo*" expanded="1|0"/>]
1446
+ </info>]
1447
+ <c id="{conv-id}" t="{tags}" n="{num-msgs}" [total="{all-msgs}"] d="{date}" f="{flags} [mbx="UID"] sf="SORT-FIELD-VALUE">
1448
+ <e ...>*
1449
+ <su>{subject}</su>
1450
+ <fr>{fragment}</fr>
1451
+ [<m id="MATCHED_MSG_ID">]+
1452
+ </c>*
1453
+ </SearchResponse>
1454
+
1455
+
1456
+ Info block:
1457
+ The <info> block is used to return general status
1458
+ information about your search. The <wildcard> element tells
1459
+ you about the status of wildcard expansions within your search
1460
+ -- if expanded=1, then the wildcard was expanded and the
1461
+ matches are included in the search. If expanded=0 then the
1462
+ wildcard was not specific enough and therefore no wildcard
1463
+ matches are included (exact-match *is* included in results).
1464
+
1465
+
1466
+ message result:
1467
+ ---------------
1468
+ <SearchResponse sortBy="sort-by" offset="..." more="{more-flag}">
1469
+ [<info>...</info>]
1470
+ <m id="{message-id}" t="{tags}" f="{flags}" s="{size}" d="{date}" cid="{conv-id}" l="{location}" [mbx="UID"] sf="SORT-FIELD-VALUE" [cm="1"]>
1471
+ <e .../>* <!- from only -->
1472
+ <su>{subject}</su>
1473
+ <fr>{fragment}</fr>
1474
+ *(<header n="{header-name}">header content</header>)
1475
+ [<mp>...</mp>] // if fetch=1, the <mp>'s of the hit (first hit only)
1476
+ <hp part="{mime-part-name}"/>+ // Hit Part -- indicator that the named part matched the search string
1477
+ </m>
1478
+ </SearchResponse>
1479
+
1480
+
1481
+ contact result:
1482
+ ---------------
1483
+ <SearchResponse offset="..." more="{more-flag}">
1484
+ [<info>...</info>]
1485
+ <cn id="id" t="tags" l="folder" sf="SORT-FIELD-VALUE" [email="Email_1 Addr"] [email2="Email_2_addr"]
1486
+ email3="Email_3_addr" [type="contact|group"] rev="REVISION" fileAsStr="..." md="{metadata-change-date}"/>
1487
+
1488
+ type is assumed to be "contact" if not present. If it is present and set to "group", then the contact is a
1489
+ personal distribution list.
1490
+
1491
+ appointment result:
1492
+ -------------------
1493
+
1494
+ <appt|task id="appointment_mail_item_id"
1495
+ t="{tags}" f="{flags}" s="{size}" d="{date}" cid="{conv-id}" // standard hit data
1496
+ l="{location}" [mbx="UID"] sf="SORT-FIELD-VALUE" // standard hit data
1497
+ [fba="F|B|T|U"]
1498
+ [transp="O|T"]
1499
+ status="TENT|CONF|CANC"
1500
+ ptst="NE|TE|AC|DE|DG"
1501
+ [allDay="1"] // if set, this is an "all day" appointment
1502
+ [otherAtt="1"] // if set, this appointment has other attendees
1503
+ [alarm="1"]
1504
+ [recur="1"] // if set, this is a recurring appointment
1505
+ [hasEx="1"] // if set, this is a recurring appointment with exceptions
1506
+ [name="NAME"] [loc="LOCATION"]
1507
+ invId="default_invite_mail_item_id" compNum="default_invite_component_number"
1508
+ isOrg="default_am_i_organizer_flag"
1509
+ [priority="num"]
1510
+ [percentComplete="num"] // only if a <task>
1511
+ [dur="duration"] // default duration; for appointments only
1512
+ >
1513
+ [<or d="friendly name" a="address">] // organizer, if available
1514
+ [<fr>DEFAULT FRAGMENT</fr>]
1515
+
1516
+ Expanded instance data -- only if calExpandInstStart and
1517
+ calExpandInstEnd are requested in the SearchRequest:
1518
+
1519
+ [ <inst
1520
+ [s="ms"] // start time in millis
1521
+ [tzo="ms"] // offset from GMT in milliseconds for start time in the
1522
+ // time zone of the instance; this is useful because the
1523
+ // instance time zone may not be the same as the time zone
1524
+ // of the requesting client; when rendering an all-day
1525
+ // appointment, the client must shift the appointment by
1526
+ // the difference between the instance time zone and its
1527
+ // local time zone to determine the correct date to render
1528
+ // the all-day block
1529
+ [dueDate="ms"] // due date in millis; for tasks only
1530
+ [tzoDue="ms"] // similar to tzo, but for dueDate; tzoDue can be different from tzo if start date
1531
+ // and due date lie on different sides of daylight savings transition
1532
+ [ex="1"]
1533
+ [ridZ="YYYYMMDD[ThhmmssZ]"] // RECURRENCE-ID in "Z" (UTC) timezone, if this is an exception
1534
+ [ANY CHANGED PARAMETERS]
1535
+ >
1536
+ [<f>FRAGMENT IF DIFFERENT FROM DEFAULT</f>]
1537
+ [<dur DURATION>] // duration this instance if not same as default
1538
+ [<isOrg>] // isOrg flag if not same as default
1539
+ [<otherAtt>] // otherAtt flag if not same as default
1540
+ </inst>
1541
+ ]+
1542
+
1543
+ Next alarm trigger time and related info:
1544
+ [ <alarmData
1545
+ nextAlarm="time in millis to show the alarm"
1546
+ alarmInstStart="start time of the meeting instance the alarm is reminding about"
1547
+ name="meeting subject"
1548
+ loc="meeting location"
1549
+ invId="invId" compNum="compNum" // these are used in GetMsg call
1550
+ >
1551
+ <alarm .../> // detail of the alarm (repeat policy, text to show, etc.)
1552
+ // See <alarm> definition in soap-calendar.txt
1553
+ </alarmData>
1554
+ ]
1555
+
1556
+ </appt|task>
1557
+
1558
+ -- fba: actual free-busy status: Free, Busy, busy-Tentative, busy-Unavailable (a.k.a. OutOfOffice)
1559
+ While free-busy status is simply a property of an event that
1560
+ is set during creation/update, "actual" free-busy status is the true
1561
+ free-busy state that depends on appt/invite free-busy, event scheduling
1562
+ status (confirmed vs. tentative vs. cancel), and more importantly, the
1563
+ attendee's participation status. For example, actual free-busy is
1564
+ busy-Tentative for an event with Busy free-busy value until the attendee
1565
+ has acted on the invite.
1566
+ -- transp: transparency: Opaque, Transparent
1567
+ -- status: status of event: TENTative, CONFirmed or CANCelled
1568
+ -- ptst: **your** participation status: NEeds-action, TEntative, ACcept, DEclined, DG (delegated)
1569
+ -- get the summary of appointments for a specified time period...
1570
+ -- otherAtt: 1 if there are other attendees to the meeting
1571
+ -- alarm: 1 if there are some alarms
1572
+ -- recur: 1 if this is a recurring appointment
1573
+ -- id is mail_item id of APPOINTMENT object
1574
+ -- invId is mail_item id of invite message with detailed information
1575
+ -- comp is component number (invite # within the message)
1576
+ -- parameters in the apptSum are "defaults" -- are same in instance unless specified
1577
+
1578
+
1579
+ message-part result:
1580
+ --------------------
1581
+ <SearchResponse offset="..." more="{more-flag}">
1582
+ [<info>...</info>]
1583
+ <mp part="{mime-part-name}" s="{size-in-bytes} mid="{message-id}"
1584
+ ct="{content-type}" name="{name}" filename="{filename}" sf="SORT-FIELD-VALUE"/>
1585
+
1586
+ </SearchResponse>
1587
+
1588
+
1589
+
1590
+ -----------
1591
+
1592
+ <SearchConvRequest cid="conversation-id" [limit="..."] [offset="..."] [sortBy="{sort-by}"] [types="{types}"] [nest="0|1"]
1593
+ [fetch="1|hits|all|{item-id}"] [max="{max-inlined-length}"] [html="1"] [read="1"] [neuter="0"] [needExp="1|0"]>
1594
+ *(<header n="{header-name}/>)
1595
+ <query>{query-string}</query>
1596
+ </SearchConvRequest>
1597
+
1598
+ {conversation-id} = the conversation to search within. REQUIRED.
1599
+
1600
+ if fetch="1" (or fetch="first"), the first matching message is expanded inline
1601
+ if fetch="hits", all matching messages are expanded inline
1602
+ if fetch="all", all messages are expanded inline
1603
+ if fetch="{item-id}", only the message with the given {item-id} is expanded inline
1604
+
1605
+ SEE SearchRequest for more info
1606
+
1607
+
1608
+ if nest="0" on the request, response looks like this:
1609
+
1610
+ <SearchConvResponse sortBy="sort-by" offset="..." more="{more-flag}">
1611
+ [<info>...</info>]
1612
+ <m id="{message-id}" [cm="1"] f="{flags}" s="{size}" d="{date}" cid="{conv-id}" sf="SORT-FIELD-VALUE">
1613
+ <e .../> <!- from only -->
1614
+ <su>{subject}</su>
1615
+ <fr>{fragment}</fr>
1616
+ *(<header n="{header-name}">header content</header>)
1617
+ [<mp>...</mp>] // if fetch=1, the <mp>'s of the hit (first hit only)
1618
+ <hp part="{mime-part-name}"/> // Hit Part -- indicator that the named part matched the search string
1619
+ </m>*
1620
+ </SearchConvResponse>
1621
+
1622
+ if nest="1" on the request, response looks like this:
1623
+
1624
+ <SearchConvResponse sortBy="sort-by" offset="..." more="{more-flag}">
1625
+ [<info>...</info>]
1626
+ <c id="{conv-id}" t="{tags}" n="{num-msgs}" [total="{all-msgs}"] f="{flags}">
1627
+ <m id="{message-id}" [cm="1"] f="{flags}" s="{size}" d="{date}" cid="{conv-id}" sf="SORT-FIELD-VALUE">
1628
+ <e .../> <!- from only -->
1629
+ <su>{subject}</su>
1630
+ <fr>{fragment}</fr>
1631
+ [<mp>...</mp>] // if fetch=1, the <mp>'s of the hit (first hit only)
1632
+ <hp part="{mime-part-name}"/> // Hit Part -- indicator that the named part matched the search string
1633
+ </m>*
1634
+ </c>
1635
+ </SearchConvResponse>
1636
+
1637
+ {cm} = 1 if the message matched the specified query string
1638
+
1639
+ SEE SearchResponse for more info
1640
+
1641
+
1642
+ If needExp is "1" in the request, and when when the 'fetch' attr is set to a
1643
+ msg ID, two additional flags will be included in <e> elements for the message:
1644
+ - isGroup: "1" if the email address is a group
1645
+ - exp: present only when isGroup="1"
1646
+ "1" if the authed user can (has permission to) expand members in this group
1647
+ "0" if the authed user does not have permission to expand group members
1648
+
1649
+ ------------
1650
+
1651
+ <BrowseRequest browseBy="{browse-by}" [regex="{regex-string}"] [maxToReturn="{max}"]/>
1652
+
1653
+
1654
+ <BrowseResponse>
1655
+ <bd freq="count">{browse-data}</bd>*
1656
+ </BrowseResponse>
1657
+
1658
+ {browse-by} = domains|attachments|objects
1659
+ {regex-string} = return only those results which match the specified regular expression
1660
+ {max} = return only a maximum number of entries as requested. If more than {max}
1661
+ results exist, the server will return the first {max}, sorted by frequency
1662
+ {browse-data} =
1663
+ for attachments: content type (application/msword)
1664
+
1665
+ for objects: object type (url, etc)
1666
+
1667
+ for domains: domains (stanford.edu, etc)
1668
+
1669
+ domain <bd> also contains the "h" attribute:
1670
+
1671
+ <bd h="{h-flags}">stanford.edu</bd>
1672
+
1673
+ which indicates whether or not the domain was from the "From", "To", or "Cc" header.
1674
+ Valid flags are always one of: "f", "t", "ft", "c", "fc", "tc", "ftc"
1675
+
1676
+ ----------
1677
+
1678
+ <GetItemRequest>
1679
+ [<item [id="{item-id}"] [path="{path}"] [l="{folder-id}"]/>]
1680
+ </GetItemRequest>
1681
+
1682
+ the caller must specify one of:
1683
+ - an {item-id},
1684
+ - a fully-qualified {path}, or
1685
+ - both a {folder-id} and a relative {path}
1686
+
1687
+ <GetItemResponse>
1688
+ <folder|m|c|cn|wiki|etc. ...>
1689
+ </GetItemResponse>
1690
+
1691
+ a successful GetItemResponse will contain a single element appropriate for the type of the requested item
1692
+ if there is no matching item, a fault containing the code mail.NO_SUCH_ITEM is returned
1693
+
1694
+ ----------
1695
+
1696
+ <GetFolderRequest [visible="0|1"] [needGranteeName="0|1"]>
1697
+ [<folder [l="{base-folder-id}"] [path="{fully-qualified-path}"]/>]
1698
+ </GetFolderRequest>
1699
+
1700
+ - either a {base-folder-id} or a {fully-qualified-path} can optionally be specified;
1701
+ if neither is present, the descent of the folder hierarchy begins at the mailbox's root folder (id 1).
1702
+ if both are present, the path is treated as relative to the folder that was specified by id
1703
+
1704
+ - if "visible" is 1, we include all visible subfolders of the specified folder
1705
+ when you have full rights on the mailbox, this is indistinguishable from the normal <GetFolderResponse>
1706
+ when you don't: folders you can see appear normally,
1707
+ folders you can't see (and can't see any subfolders) are omitted
1708
+ folders you can't see (but *can* see >=1 subfolder) appear as <folder id="{id}" name="{name}"> hierarchy placeholders
1709
+
1710
+ - if *no* folders are visible and visible=1, the response looks like <GetFolderResponse/>
1711
+
1712
+ - if "needGranteeName" is 0, grantee names in in forlder grants (the d attribute in <grant>) are omitted.
1713
+ default for needGranteeName is 1.
1714
+
1715
+ <GetFolderResponse>
1716
+ <folder ...>
1717
+ <folder .../>
1718
+ <folder ...>
1719
+ <folder .../>
1720
+ </folder>
1721
+ <folder .../>
1722
+ [<link .../>]
1723
+ [<search .../>]
1724
+ </folder>
1725
+ </GetFolderResponse>
1726
+
1727
+ GetFolderResponse always has exactly 1 folder element within it. Without a base
1728
+ folder ID that folder element will represent the virtual root folder.
1729
+
1730
+ Mountpoints are handled in one of two ways, depending on the type of the <folder>
1731
+ in the request. When <folder> is a mountpoint, the mountpoint is
1732
+ validated and all of its subfolders are returned. When <folder> is not specified
1733
+ or it is a regular folder, any subfolders that are mountpoints are not validated,
1734
+ and subfolders of the mountpoint are not returned.
1735
+
1736
+ ----------
1737
+
1738
+ <GetConvRequest>
1739
+ <c id="{conv-id}" [fetch="1|all|{item-id}" max="{max-inlined-length}" html="0|1"]>
1740
+ *(<header n="{header-name}/>)
1741
+ </c>
1742
+ </GetConvRequest>
1743
+
1744
+ GetConvRequest gets information about the 1 conversation named by id's value.
1745
+ It will return exactly 1 conversation element.
1746
+
1747
+ if fetch="1|all" is included, the full expanded message structure is inlined
1748
+ for the first (or for all) messages in the conversation
1749
+ if fetch="{item-id}", only the message with the given {item-id} is expanded inline
1750
+
1751
+ if <header>s are requested, any matching headers are inlined into the response
1752
+ (not available when raw="1")
1753
+
1754
+ <GetConvResponse>
1755
+ <c id="{conv-id}" [t="{tags}"] n="{num-msgs}" [total="{all-msgs}"] [f="{flags}"]>
1756
+ <su>{subject}</su>
1757
+ <m id="{message-id}" [f="{flags}"] s="{size}" d="{date}" [t="{tags}"]>
1758
+ <e .../>
1759
+ <fr>{fragment}</fr>
1760
+ </m>+
1761
+ </c>
1762
+ </GetConvResponse>
1763
+
1764
+ ------------
1765
+
1766
+ <GetMsgRequest>
1767
+ <m id="{msg-id}" [read="1"] [raw="1"] [max="{max-inlined-length}"] [html="1"] [neuter="0"] [part="{part}"]
1768
+ [ridZ="YYYYMMDD[ThhmmssZ]"] [needExp="1|0"]
1769
+ >
1770
+ *(<header n="{header-name}/>)
1771
+ </m>
1772
+ </GetMsgRequest>
1773
+
1774
+ The {msg-id} can contain a subpart identifier (e.g. "775-778") to return
1775
+ a message stored as a subpart of some other mail-item, specifically for
1776
+ Messages stored as part of Appointments
1777
+
1778
+ read="1" to mark the message as read, "0" to leave the read status unchanged.
1779
+ (default is 0.)
1780
+ raw="1" to return the raw message content rather than a parsed mime structure;
1781
+ (default is "0". if message too big or not ASCII, a content servlet URL is returned)
1782
+ max="{max-inlined-length}" to limit the length of the text inlined into body <content> when raw="0"
1783
+ (default is "0", meaning no limit.)
1784
+ html="1" to return defanged HTML content by default.
1785
+ (default is 0.)
1786
+ neuter="1" to "neuter" <IMG> tags returned in HTML content; this involves switching
1787
+ the "src" attribute to "dfsrc" so that images don't display by default
1788
+ (default is 1.)
1789
+ supply a "part" and the retrieved data will be on the specified message/rfc822 subpart.
1790
+ if the part does not exist or is not a message/rfc822 part, mail.NO_SUCH_PART
1791
+
1792
+ ridZ="YYYYMMDD[ThhmmssZ]" is used only when making GetMsg call to open an instance of a recurring appointment.
1793
+ the value specified is the date/time data of the RECURRENCE-ID of the instance being requested
1794
+
1795
+ needExp="1" to return group info (isGroup and exp flags) on <e> elements in the response
1796
+ (default is 0.)
1797
+
1798
+ if <header>s are requested, any matching headers are inlined into the response
1799
+ (not available when raw="1")
1800
+
1801
+ <GetMsgResponse>
1802
+ <m id="{message-id}" [origid="..." rt="r|w"] [part="{part}"] f="{flags}" t="{tags}" s="{size}" [d="{received-date}"] sd="{date-header}" l="{folder}" (cid="{conv}")
1803
+ (cif="{X-Zimbra-Calendar-Intended-For header}")
1804
+ >
1805
+ <e ... [isGroup="1|0"] [exp="1|0"]/>*
1806
+ <su>{subject}</su>
1807
+ <fr>{fragment}</fr>
1808
+ [<irt>{Message-ID header for message being replied to}</irt>]
1809
+ <mid>{Message-ID header}</mid>
1810
+ *(<header n="{header-name}">header content</header>)
1811
+ [<mp>...</mp>]
1812
+ [<shr><content>{share-announcement-in-xml}</content</shr>]
1813
+ [<content (url="...")>...</content>]
1814
+ </m>
1815
+ </GetMsgResponse>
1816
+
1817
+ origid/rt/irt are present only on drafts
1818
+ cif is set when the message is a calendar invite that was forwarded by another user, whose calendar is being
1819
+ managed by this user. The attribute is set to the email of the forwarding user, for whom the invite was
1820
+ originally intended.
1821
+
1822
+
1823
+ If needExp is "1" in the request, two additional flags will be included in <e> elements for the message:
1824
+ - isGroup: "1" if the email address is a group
1825
+ - exp: present only when isGroup="1"
1826
+ "1" if the authed user can (has permission to) expand members in this group
1827
+ "0" if the authed user does not have permission to expand group members
1828
+
1829
+ ------------
1830
+ <GetMsgMetadataRequest>
1831
+ <m ids="{msg-id-list}"/>
1832
+ </GetMsgMetadataRequest>
1833
+
1834
+ <GetMsgMetadataResponse>
1835
+ (<m id="{message-id}" f="{flags}" t="{tags}" s="{size}" d="{received-date}" l="{folder}" [cid="{conv}"]
1836
+ rev="{revision-number}" md="{date-metadata-changed}" ms="{change-sequence}"/>)*
1837
+ </GetMsgMetadataResponse>
1838
+
1839
+ ------------
1840
+
1841
+ <CreateFolderRequest>
1842
+ <folder name="..." [l="{parent-folder}"] [fie="1"] [view="{default-type}"] [color="{color}"] [rgb="{rgb-color}"] [f="{flags}"] [url="{url}"] [sync="1"]>
1843
+ [<acl> <grant perm="{rights}" gt="{grantee-type}" zid="{zimbra-id}" d="{grantee-name}" [pw="{password-for-guest}"] [key="{access-key}"]/>* </acl>]
1844
+ </folder>
1845
+ </CreateFolderRequest>
1846
+
1847
+ - if l is unset, name is the full path of the new folder; otherwise, name may not contain the folder separator '/'
1848
+ - if fie="1" is set, the server will fetch the folder if it already exists rather than throwing mail.ALREADY_EXISTS
1849
+ - if url is set and sync="1" (default), synchronize folder content on folder creation
1850
+
1851
+ <CreateFolderResponse>
1852
+ <folder id="..." name="..." l="{parent-folder}" [u="{unread count}"] [n="{msg count}"]/>
1853
+ </CreateFolderResponse>
1854
+
1855
+ - name and l are omitted on response for root folder
1856
+ - u and/or n attributes are present on response iff count > 0
1857
+
1858
+ ---------
1859
+
1860
+ <ItemActionRequest>
1861
+ <!-- action can be preceeded by a "!" to negate it" -->
1862
+ <action id="{list}" op="delete|dumpsterdelete|recover|read|flag|tag|move|trash|rename|update|color|lock|unlock"
1863
+ [tag="{id}"] [l="{folder}"] [name="{item-name}"] [color="{color}"] [rgb="{rgb-color}"]
1864
+ [tcon="[-]{constraint}"] [f="{flags}"] [t="{id-list}"]/>
1865
+ </ItemActionRequest>
1866
+
1867
+ <ItemActionResponse>
1868
+ <action id="{list}" op="delete|read|flag|tag|move|trash|rename|update"/>
1869
+ </ItemActionResponse>
1870
+
1871
+ {list} = on input, list of items to act on, on output, list of
1872
+ items that were acted on
1873
+ [-]{constraint} = list of characters; constrains the set of affected items in a conversation
1874
+ t - include items in the Trash
1875
+ j - include items in Spam/Junk
1876
+ s - include items in the user's Sent folder (not necessarily "Sent")
1877
+ o - include items in any other folder
1878
+ a leading '-' means to negate the constraint (e.g. "-t" means all messages not in Trash)
1879
+
1880
+ For op="update", caller can specify any or all of: l="{folder}", name="{name}", color="{color}",
1881
+ t="{tag-id-list}", f="{flags}". When modifying tags or flags, all specified tags and flags
1882
+ are set, and all others are unset.
1883
+
1884
+ In op="delete" action, the item is either permanently deleted if dumpster is not in use, or
1885
+ soft deleted to the dumpster.
1886
+
1887
+ In op="dumpsterdelete" action, the item in the dumpster is permanently deleted.
1888
+
1889
+ For op="recover", caller must specify l="{folder}". The item is recovered from dumpster as a copy
1890
+ in the specified folder. The dumpster copy is then deleted.
1891
+
1892
+ For op="tag" or op="!tag", caller must specify tag="{id}". This changes the state of
1893
+ the specified tag without altering other tags.
1894
+
1895
+ A trash operation on a remote item will cause it to be moved to the trash folder of its
1896
+ remote mailbox, not the local mailbox.
1897
+
1898
+ <action op="color" id="{list}" color="{new-color} rgb="{new-color-in-rgb}"/>
1899
+ - change the item's color to new color. only one of color or rgb attribute
1900
+ needs to be present. if both are present rgb value takes precedence.
1901
+ rgb is specified as CSS style #rrggbb
1902
+
1903
+ The <action> element in the response always contains the same id list that the client
1904
+ sent in the request. Id's that were ignored due to constraints are included in the
1905
+ id list.
1906
+
1907
+ ---------
1908
+
1909
+ <MsgActionRequest>
1910
+ <!-- action can be preceeded by a "!" to negate it" -->
1911
+ <action id="{list}" op="delete|read|flag|tag|move|update|spam|trash" [tag="{id}"] [l="{folder}"] [f="{flags}"] [t="{tag-id-list}"] [color="{color}"]/>
1912
+ </MsgActionRequest>
1913
+
1914
+ <MsgActionResponse>
1915
+ <action id="{list}" op="delete|read|flag|tag|move|update|spam|trash"/>
1916
+ </MsgActionResponse>
1917
+
1918
+ {list} = on input, list of messages to act on, on output, list of
1919
+ messages that were acted on
1920
+ list may only have 1 element for action "spam"
1921
+
1922
+ For op="update", caller can specify any or all of: l="{folder}", name="{name}", color="{color}",
1923
+ t="{tag-id-list}", f="{flags}".
1924
+
1925
+ for op="!spam", can optionally specify a destination folder
1926
+
1927
+ See <ItemActionRequest> for more details.
1928
+
1929
+ ---------
1930
+
1931
+ <ConvActionRequest>
1932
+ <!-- action can be preceeded by a "!" to negate it" -->
1933
+ <action id="{list}" op="delete|read|flag|tag|move|spam|trash" [tag="{id}"] [l="{folder}"] [tcon="{constraint}"] [tcon="[-]{constraint}"]/>
1934
+ </ConvActionRequest>
1935
+
1936
+ <ConvActionResponse>
1937
+ <action id="{list}" op="delete|read|flag|tag|move|spam|trash"/>
1938
+ </ConvActionResponse>
1939
+
1940
+ {list} = on input, list of conversations to act on, on output, list of
1941
+ conversations that were acted on
1942
+ list may only have 1 element for action "spam"
1943
+ [-]{constraint} = list of characters; constrains the set of affected items in a conversation
1944
+ t - include items in the Trash
1945
+ j - include items in Spam/Junk
1946
+ s - include items in the user's Sent folder (not necessarily "Sent")
1947
+ o - include items in any other folder
1948
+ a leading '-' means to negate the constraint (e.g. "-t" means all messages not in Trash)
1949
+
1950
+ for op="!spam", can optionally specify a destination folder
1951
+
1952
+ See <ItemActionRequest> for more details.
1953
+
1954
+ ---------
1955
+
1956
+ <FolderActionRequest>
1957
+ <action id="{list}" op="read|delete|rename|move|trash|empty|color|[!]grant|revokeorphangrants|url|import|sync|fb|[!]check|update|[!]syncon" [l="{target-folder}"]
1958
+ [name="{new-name}"] [color="{new-color}"] [rgb="{rgb-color}"] [zid="{grantee-zimbra-id}"] [url="{target-url}"]
1959
+ [excludeFreeBusy="{exclude-free-busy-boolean}">
1960
+ [<grant perm="..." gt="..." d="..." [pw="..."] [key="..."]/>]
1961
+ </action>
1962
+ </FolderActionRequest>
1963
+
1964
+ <FolderActionResponse>
1965
+ <action id="{list}" op="read|delete|empty|rename|move|trash|color|grant|url|import|sync|fb|[!]check|update" [zid="{grantee-zimbra-id}"]/>
1966
+ </FolderActionResponse>
1967
+
1968
+ Actions:
1969
+ <action op="read" id="{list}"/>
1970
+ - mark all items in the folder as read
1971
+
1972
+ <action op="delete" id="{list}"/>
1973
+ - hard-delete the folder, all items in the folder, and all the folder's subfolders
1974
+
1975
+ <action op="empty" id="{list}" [recusive="{delete-subfolders}"]/>
1976
+ - hard-delete all items in the folder (and all the folder's subfolders if "recursive" is set)
1977
+
1978
+ <action op="rename" id="{list}" name="{new-name}" [l="{new-folder}"]/>
1979
+ - change the folder's name (and optionally location);
1980
+ if {new-name} begins with '/', the folder is moved to the new path and any missing path elements are created
1981
+
1982
+ <action op="move" id="{list}" l="{new-folder}"/>
1983
+ - move the folder to be a child of {target-folder}
1984
+
1985
+ <action op="trash" id="{list}"/>
1986
+ - move the folder to the Trash, marking all contents as read and
1987
+ renaming the folder if a folder by that name is already present in the Trash
1988
+
1989
+ <action op="color" id="{list}" color="{new-color} rgb="{new-color-in-rgb}"/>
1990
+ - see ItemActionRequest
1991
+
1992
+ <action op="grant" id="{list}">
1993
+ <grant perm="..." gt="..." d="..." [pw="..."] [key="..."]/>
1994
+ </action>
1995
+ - add the <grant> object to the folder
1996
+
1997
+ <action op="!grant" id="{list}" zid="{grantee-zimbra-id}"/>
1998
+ - revoke access from {grantee-zimbra-id}
1999
+ (you can use "00000000-0000-0000-0000-000000000000" to revoke acces granted to "all"
2000
+ or use "99999999-9999-9999-9999-999999999999" to revoke acces granted to "pub" )
2001
+
2002
+ <action op="revokeorphangrants" id="{folder-id}" zid="{grantee-zimbra-id}" gt="{grantee-type}"/>
2003
+ - revoke orphan grants on the folder hierarchy granted to the grantee specified by zid and gt
2004
+ "orphan grant" is a grant whose grantee object is deleted/non-existing. Server will throw
2005
+ INVALID_REQUEST if zid points to an existing object,
2006
+ Only supported if gt is usr|grp|cos|dom; otherwise server will throw INVALID_REQUEST.
2007
+
2008
+ <action op="url" id="{list}" url="{target-url}" [excludeFreeBusy="{exclude-free-busy-boolean}"]/>
2009
+ - set the synchronization url on the folder to {target-url}, empty the folder, and\
2010
+ synchronize the folder's contents to the remote feed, also sets {exclude-free-busy-boolean}
2011
+
2012
+ <action op="sync" id="{list}"/>
2013
+ - synchronize the folder's contents to the remote feed specified by the folder's {url}
2014
+
2015
+ <action op="import" id="{list}" url="{target-url}"/>
2016
+ - add the contents to the remote feed at {target-url} to the folder [1-time action]
2017
+
2018
+ <action op="fb" id="{list}" excludeFreeBusy="{exclude-free-busy-boolean}"/>
2019
+ - set the excludeFreeBusy boolean for this folder (must specify {exclude-free-busy-boolean})
2020
+
2021
+ <action op="[!]check" id="{list}"/>
2022
+ - set or unset the "checked" state of the folder in the UI
2023
+
2024
+ <action op="[!]syncon" id="{list}"/>
2025
+ - set or unset the "sync" flag of the folder to sync a local folder with a remote source
2026
+
2027
+ <action op="update" id="{list}" [f="{new-flags}"] [name="{new-name}"] [l="{target-folder}"] [color="{new-color}"]>
2028
+ [<acl><grant .../>*</acl>]
2029
+ </action>
2030
+ - do several operations at once:
2031
+ name="{new-name}" to change the folder's name
2032
+ l="{target-folder}" to change the folder's location
2033
+ color="{new-color}" to set the folder's color
2034
+ f="{new-flags}" to change the folder's exclude free/(b)usy, checked (#), and IMAP subscribed (*) state
2035
+ <acl><grant ...>*</acl> to replace the folder's existing ACL with a new ACL
2036
+
2037
+ {list} = on input, list of folders to act on, on output, list of
2038
+ folders that were acted on;
2039
+ list may only have 1 element for action "rename" or "empty"
2040
+
2041
+ output of "grant" action includes the zimbra id the rights were granted on
2042
+
2043
+ note that "delete", "empty", "rename", "move", "color", "update" can be used on search folders as well as standard folders
2044
+
2045
+ ---------
2046
+
2047
+ <TagActionRequest>
2048
+ <action op="read|rename|color|delete|update" id="..." [name="..."] [color="..."]/>
2049
+ </TagActionRequest>
2050
+
2051
+ - if op="update", the caller can specify "name" and/or "color"
2052
+
2053
+ <TagActionResponse>
2054
+ <action op="read|rename|color|delete|update" id="..."/> <!-- iff op was successful -->
2055
+ </TagActionResponse>
2056
+
2057
+ --------------
2058
+
2059
+ <GetTagRequest/>
2060
+
2061
+ <GetTagResponse>
2062
+ <tag id="..." name="..." color="..." [u="{unread_count}"]/>+
2063
+ </GetTagResponse>
2064
+
2065
+ u attribute is present iff count > 0
2066
+ ---------
2067
+
2068
+ <CreateTagRequest>
2069
+ <tag name="..." (color="...")/>
2070
+ </CreateTagRequest>
2071
+
2072
+ <CreateTagResponse>
2073
+ <tag (same as GetTagResponse)/>
2074
+ </CreateTagResponse>
2075
+
2076
+ ---------
2077
+
2078
+ <GetSearchFolderRequest>
2079
+ <!-- get all by default -->
2080
+ </GetSearchFolderRequest>
2081
+
2082
+ <GetSearchFolderResponse>
2083
+ <search id="..." name="..." query="..." [types="..."] [sortBy="..."] l="{folder}"/>+
2084
+ </GetSearchFolderResponse>
2085
+
2086
+ ---------
2087
+
2088
+ <CreateSearchFolderRequest>
2089
+ <search name="..." query="..." [types="..."] [sortBy="..."] l="{folder}" [f="{flags}"] [color="{color}"]/>
2090
+ </CreateSearchFolderRequest>
2091
+
2092
+ <CreateSearchFolderResponse>
2093
+ <search id="..." name="..." query="..." [types="...] [sortBy="..."] l="{folder}"/>
2094
+ </CreateSearchFolderResponse>
2095
+
2096
+ ---------
2097
+
2098
+ <ModifySearchFolderRequest>
2099
+ <search id="..." query="..." [types="..."] [sortBy="..."]/>
2100
+ </ModifySearchFolderRequest>
2101
+
2102
+ <ModifySearchFolderResponse>
2103
+ <search id="..." name="..." query="..." [types="...] [sortBy="..."] l="{folder}"/> <!-- iff it was modified -->
2104
+ </ModifySearchFolderResponse>
2105
+
2106
+ ---------
2107
+
2108
+ <CreateMountpointRequest>
2109
+ <link l="{folder}" name="{mountpoint-name}" [view="..."] [color="{color}"] [rgb="{rgb-color}"] [f="{flags}"] [fie="1"]
2110
+ [zid="{owner's-zimbra-id}" | owner="{owner's-email-address}"] [rid="{id-of-shared-item}" | path="{path-to-shared-item}"]/>
2111
+ </CreateMountpointRequest>
2112
+
2113
+ - caller must specify one of (zid | owner) and one of (rid | path)
2114
+
2115
+ <CreateMountpointResponse>
2116
+ <link id="{created-link-item-id}" l="{folder}" name="..." [view="..."]/>
2117
+ </CreateMountpointResponse>
2118
+
2119
+ ---------
2120
+
2121
+ # origid will be present if this is a reply or forward
2122
+ # TODO: indicate whether to save in SentMail (or some other folder)
2123
+
2124
+ + add="1" on recipient email address means to add to caller's address book (no duplicate checking!)
2125
+ + supports (f)rom, (t)o, (c)c, (b)cc, (r)eply-to, (s)ender, read-receipt (n)otification "type" on <e> elements
2126
+ + only allowed one top-level <mp> but can nest <mp>s within if multipart/*
2127
+ + a leaf <mp> can have inlined content (<mp ct="{content-type}"><content>...</content></mp>)
2128
+ + a leaf <mp> can have referenced content (<mp><attach ...></mp>)
2129
+ + any <mp> can have a Content-ID header attached to it
2130
+ + on reply/forward, set origid on <m> element and set rt to "r" or "w", respectively
2131
+ + can optionally set identity-id to specify the identity being used to compose the message
2132
+ + if noSave="1", a copy will *not* be saved to sent regardless of account/identity settings
2133
+ + can set priority high (!) or low (?) on sent message by specifying "f" attr on <m>
2134
+
2135
+ <SendMsgRequest [suid="{send-uid}"] [needCalendarSentByFixup="0|1"] [noSave="0|1"]>
2136
+ <m [f="!|?"] [origid="..." rt="r|w"] [idnt="{identity-id}"] [did="{saved-draft-id}"]>
2137
+ <e t="{type}" a="{email-address}" p="{personal-name}" [add="1"]/>+
2138
+ <su>{subject}</su>*
2139
+ [<header name="{header-name}">{header-value}</header>]*
2140
+ [<irt>{Message-ID header for message being replied to}</irt>]
2141
+ <mp ct="{content-type}" [ci="{content-id}"]>
2142
+ <content>...</content>
2143
+ </mp>
2144
+ <attach [aid="{attach-upload-id}[,{attach-upload-id}]"]>
2145
+ [<m id="{message-id}" [optional="0|1"]/>]*
2146
+ [<mp mid="{message-id}" part="{part-id}" [optional="0|1"]/>]*
2147
+ [<cn id="{contact-id}" [optional="0|1"]/>]*
2148
+ [<doc (id="{document-id}" | path="{document-path}") [optional="0|1"]/>]*
2149
+ </attach>
2150
+ </m>
2151
+ </SendMsgRequest>
2152
+
2153
+ or, if you want to compose the message remotely, upload it via
2154
+ FileUploadServlet, and submit it through our server:
2155
+
2156
+ <SendMsgRequest [suid="{send-uid}"] [needCalendarSentByFixup="0|1"]>
2157
+ <m aid="{uploaded-MIME-body-ID}" [origid="..." rt="r|w"]/>
2158
+ </SendMsgRequest>
2159
+
2160
+ # If the message is saved to the sent folder then the id of the message is returned.
2161
+ # Otherwise, no id is returned -- just a <m></m> is returned.
2162
+ <SendMsgResponse>
2163
+ <m id="..." />
2164
+ </SendMsgResponse>
2165
+
2166
+ needCalendarSentByFixup - Add SENT-BY parameter to ORGANIZER and/or ATTENDEE
2167
+ properties in iCalendar part when sending message
2168
+ on behalf of another user
2169
+ default is 0
2170
+
2171
+ {send-uid} - an optional client-generated unique identifier string for the send
2172
+ if the SendMsg request is re-sent but the message has not been modified, the client should use
2173
+ the same {send-uid} and the server will try to check the status of the previous SendMsg attempt
2174
+
2175
+ {header-name}, {header-value} - custom RFC822 header name and value respectively. Only header names specified in
2176
+ zimbraCustomMimeHeaderNameAllowed global config are allowed for security reasons.
2177
+
2178
+ ----------------------------
2179
+
2180
+ # origid will be present if this is a reply or forward
2181
+ # Can we have more than one From: address?
2182
+ # TODO: indicate folder to save in (defaults to Drafts)
2183
+
2184
+ + only allowed one top-level <mp> but can nest <mp>s within if multipart/*
2185
+ + on reply/forward, set origid on <m> element and set rt to "r" or "w", respectively
2186
+ + can optionally set identity-id to specify the identity being used to compose the message
2187
+ + if updating an existing draft, set "id" attr on <m> element
2188
+ + can refer to parts of existing draft in <attach> block
2189
+ + drafts default to the Drafts folder
2190
+ + setting folder/tags/flags/color occurs *after* the draft is created/updated, and if it fails the content *WILL STILL BE SAVED*
2191
+ + can optionally set autoSendTime to specify the time at which the draft should be automatically sent by the server
2192
+
2193
+ <SaveDraftRequest>
2194
+ <m [id="{existing-draft-id}"] [origid="..." rt="r|w"] [idnt="{identity-id}"] [l="{folder}"] [f="{flags}"] [t="{tag-id-list}"] [color="{color}"] [autoSendTime="{millis-since-epoch}"]>
2195
+ <e t="{type}" a="{email-address}" p="{personal-name}"/>+
2196
+ <su>{subject}</su>*
2197
+ [<header name="{header-name}">{header-value}</header>]*
2198
+ [<irt>{Message-ID header for message being replied to}</irt>]
2199
+ <mp ct="{content-type}">
2200
+ <content>...</content>
2201
+ </mp>
2202
+ <attach [aid="{attach-upload-id}"]>
2203
+ [<m id="{message-id}" [optional="0|1"]/>]*
2204
+ [<mp mid="{message-id}" part="{part-id}" [optional="0|1"]/>]*
2205
+ [<cn id="{contact-id}" [optional="0|1"]/>]*
2206
+ [<doc (id="{document-id}" | path="{document-path}") [optional="0|1"]/>]*
2207
+ </attach>
2208
+ </m>
2209
+ </SaveDraftRequest>
2210
+
2211
+ or, if you want to compose the message remotely, upload it via
2212
+ FileUploadServlet, and submit it through our server:
2213
+
2214
+ <SaveDraftRequest>
2215
+ <m aid="{uploaded-MIME-body-ID}" [id="{existing-draft-id}"]
2216
+ [origid="..." rt="r|w"] [l="{folder}"] [f="{flags}"] [t="{tag-id-list}"] [color="{color}"] [autoSendTime="{millis-since-epoch}"]/>
2217
+ </SaveDraftRequest>
2218
+
2219
+
2220
+ # The id of the saved draft is returned
2221
+ <SaveDraftResponse>
2222
+ <m id="{message-id}" f="{flags}" t="{tags}" s="{size}" [d="{received-date}"]
2223
+ sd="{date-header}" l="{folder}" (cid="{conv}") [autoSendTime="{millis-since-epoch}"]
2224
+ [idnt="{identity-id}"]>
2225
+ <e .../>*
2226
+ <su>{subject}</su>
2227
+ <irt>{Message-ID header for message being replied to}</irt>
2228
+ <fr>{fragment}</fr>
2229
+ <mid>{Message-ID header}</mid>
2230
+ [<mp>...</mp>]
2231
+ [<content (url="...")>...</content>]
2232
+ </m>
2233
+ </SaveDraftResponse>
2234
+
2235
+ The identity referenced by {identity-id} specifies the folder where the sent message
2236
+ is saved.
2237
+
2238
+ ----------------------------
2239
+
2240
+ <SendDeliveryReportRequest mid="{message-id}"/>
2241
+
2242
+ <SendDeliveryReportResponse/>
2243
+
2244
+ ----------------------------
2245
+
2246
+ <AddMsgRequest [filterSent="0|1"]>
2247
+ <m l="{folder}" [f="{flags}"] [t="{tags}"] [d="{received-date}"] [aid="{uploaded-MIME-body-ID}"] [noICal="0|1"]>
2248
+ <content>
2249
+ ...
2250
+ </content>
2251
+ [
2252
+ <inv uid="UID">...</inv> # MUST have UID
2253
+ ]
2254
+ ...
2255
+ </m>
2256
+ </AddMsgRequest>
2257
+
2258
+ {flags} = (u)nread, (f)lagged, has (a)ttachment, (r)eplied, (s)ent by me, for(w)arded,
2259
+ (d)raft, deleted (x), (n)otification sent
2260
+ {tags} = comma-separated list of tag IDs
2261
+ {folder} = folder pathname (starts with '/') or folder ID
2262
+ {received-date} = (optional) time the message was originally received, in MILLISECONDS since the epoch
2263
+ {uploaded-MIME-body-ID} = ID of message uploaded via FileUploadServlet
2264
+ {noICal} = if TRUE, then don't process iCal attachments. Default is FALSE.
2265
+ TODO: even if noICal is true, calendar should still link message to existing appointment
2266
+ (by UID) if the appointment already exists.
2267
+ {filterSent} = If TRUE, then do outgoing message filtering if the msg is being added to the Sent
2268
+ folder and has been flagged as sent. Default value is FALSE.
2269
+
2270
+ Note that the <m> element should include the <content> element with the
2271
+ entire message's content. (Omit <content> if you specify an "aid" attribute.)
2272
+ No <mp> elements should be provided within <m>.
2273
+
2274
+ # Returns the Message's ID just created
2275
+ <AddMsgResponse>
2276
+ <m id="{message-id}" f="{flags}" t="{tags}" s="{size}" d="{received-date}" l="{folder}" [cid="{conv}"]
2277
+ rev="{revision-number}" md="{date-metadata-changed}" ms="{change-sequence}"/>
2278
+ </AddMsgResponse>
2279
+
2280
+ ----------------------------
2281
+
2282
+ <RemoveAttachmentsRequest>
2283
+ <m id="{message-id}" part="{list-of-part-ids-to-remove}">
2284
+ </RemoveAttachmentsRequest>
2285
+
2286
+ {list-of-part-ids-to-remove} = comma-separated list of part IDs to strip from existing message body
2287
+
2288
+ # NOTE that this operation is effectively a create and a delete, and thus the message's item ID will change
2289
+
2290
+ <RemoveAttachmentsResponse>
2291
+ <m id="{message-id}" f="{flags}" t="{tags}" s="{size}" d="{received-date}" l="{folder}" [cid="{conv}"]
2292
+ rev="{revision-number}" md="{date-metadata-changed}" ms="{change-sequence}"/>
2293
+ </RemoveAttachmentsResponse>
2294
+
2295
+ ----------------------------
2296
+
2297
+ Contacts:
2298
+
2299
+ <cn id="{contact-id}" [t="{tags}"] [f="{flags}"] md="{modified-date}" [l="{folder}"] [fileAsStr="{file-as}"]>
2300
+ <a n="{attr-name}">{attr-data}</a>+
2301
+ <a n="{attr-name}" aid="{upload-id}"/>*
2302
+ <a n="{attr-name}" id="{item-id}" [part="{subpart-name}"]/>*
2303
+ <a n="{attr-name}" part="{part-id}"/>* <-- only valid when modifying an existing contact -->
2304
+ </cn>
2305
+
2306
+ {contact-id} = unique contact id
2307
+ {flags} = (f)lagged, has (a)ttachment
2308
+ {modified-date} = secs since epoch, date contact was modified
2309
+ {file-as} = current "file as" string for display/sorting purposes; *cannot* be used to *set* the file-as value
2310
+ {attr-name} = name of the attribute (firstName, etc)
2311
+
2312
+ {folder-id} = id of folder to create contact in. Un-specified means use the default Contacts folder.
2313
+
2314
+ to add attachments, specify an {upload-id} instead of providing {attr-data} on the attr
2315
+ alternatively, specify an {item-id} to attach, with an optional {subpart-name} for contacts and messages
2316
+ when editing an existing contact, can omit the {item-id} and we'll assume it's the contact being edited
2317
+
2318
+ when contacts are returned, they look like:
2319
+
2320
+ <cn id="{contact-id}" t="{tags}" f="{flags}" md="{modified-date}" l="{folder}" fileAsStr="{file-as}">
2321
+ <a n="{attr-name}">{attr-data}</a>+
2322
+ <a n="{attr-name}" size="{attach-size}" ctype="{attach-content-type}" filename="{attach-filename}" part="{part-id}"/>*
2323
+ </cn>
2324
+
2325
+ ----------
2326
+
2327
+ <CreateContactRequest [verbose="0|1"]>
2328
+ <cn [l="{folder-id}"] [t="{tags}"]>
2329
+ <a>...</a>+
2330
+ </cn>
2331
+ </CreateContactRequest>
2332
+
2333
+ or, if you have an existing vCard to add, you can specify a <vcard> element with *one* of
2334
+ -- inlined content
2335
+ -- mid/part attributes specifying an existing message part
2336
+ -- aid attribute specifying an uploaded text/calendar file
2337
+
2338
+ <CreateContactRequest [verbose="0|1"]>
2339
+ <cn [l="{folder-id}"] [t="{tags}"]>
2340
+ <vcard [mid="{message-id}" part="{part-identifier}] [aid={uploaded-attachment-id"}"]>
2341
+ [BEGIN:VCARD
2342
+ ...
2343
+ END:VCARD]
2344
+ </vcard>
2345
+ </cn>
2346
+ </CreateContactRequest>
2347
+
2348
+
2349
+ <CreateContactResponse>
2350
+ (<cn> definition above)
2351
+ </CreateContactResponse>
2352
+
2353
+ {folder-id} = id of folder to create contact in. Un-specified means use the default Contacts folder.
2354
+ {tags} = list of tags to apply to the created contact
2355
+
2356
+ -- if "verbose='0'" (defaults to '1') was specified on the request, the returned <cn>
2357
+ is just a placeholder containing the new contact ID (i.e. <cn id="{id}"/>)
2358
+
2359
+ ----------
2360
+
2361
+ <ModifyContactRequest [replace="{replace-mode}"] [verbose="0|1"]>
2362
+ <cn id="...">
2363
+ <a n="{name}" [op="{op}"]>{attr-value}</a>+
2364
+ </cn>
2365
+ </ModifyContactRequest>
2366
+
2367
+ {attr-value} = new attribute value. If empty (<a/>), then the attribute will be removed.
2368
+
2369
+ {replace-mode} = 0|1 (0 is default)
2370
+
2371
+ if replace-mode is 1, all attrs in the specified contact are replaced with specified attrs, otherwise
2372
+ the attrs are merged with the existing contact.
2373
+
2374
+ {op} = + | -
2375
+ + : add the value
2376
+ - : remvoe the value
2377
+
2378
+ {op} is not allowed if replace-mode is 1, if specified when replace=1, INVALID_REQUEST will be thrown
2379
+
2380
+ When replace=0:
2381
+ (1) if op is not present:
2382
+ if {attr-value} is empty, remove the field
2383
+ otherwise, replace the field with this value
2384
+
2385
+ (2) if op is present:
2386
+ if {attr-value} is empty, throw INVALID_REQUEST
2387
+ - otherwise, add/remove the specified value.
2388
+
2389
+
2390
+ <ModifyContactResponse>
2391
+ <cn ...>
2392
+ <a n="...">...</a>
2393
+ ...
2394
+ </cn>
2395
+ </ModifyContactResponse>
2396
+
2397
+ NOTE: should we return modified attrs in response?
2398
+
2399
+ -- if verbose='0' (defaults to '1') was specified on the request, the returned <cn>
2400
+ is just a placeholder containing the contact ID (i.e. <cn id="{id}"/>)
2401
+
2402
+ ----------
2403
+
2404
+ <GetContactsRequest [sortBy="nameAsc|nameDesc"] [sync="1"] [l="{folder-id}"]
2405
+ [returnHiddenAttrs="1"] [maxMembers="{max-members}"]>
2406
+ <a n="..."/>*
2407
+ <cn id="{contact-id}[,{contact-id}...]"/>*
2408
+ </GetContactsRequest>
2409
+
2410
+ if sync="1" present, return modified date (md) on contacts.
2411
+ if l="{folder-id}" is present, return only contacts in the specified folder.
2412
+ if <a n="..."/> present, return only the specified attribute(s).
2413
+ if <cn id="..."/> present, only get the specified contact(s).
2414
+
2415
+
2416
+ returnHiddenAttrs : whether to return contact hidden attrs defined in zimbraContactHiddenAttributes.
2417
+ ignored if <a> is present.
2418
+ {max-members} : numebr of max GAL group members to return.
2419
+ If number of members on a GAL group is greater than the specified max,
2420
+ do not return any members under <cn> for the entry.
2421
+ Instead, return a "tooManyMembers="1" on the <cn>.
2422
+
2423
+ <GetContactsResponse>
2424
+ <cn [md="{metadata-change-date}"] [tooManyMembers="1"]>...</cn>*
2425
+ </GetContactsResponse>
2426
+
2427
+ ----------
2428
+
2429
+ <ContactActionRequest>
2430
+ <!-- some actions can be preceeded by a "!" to negate them -->
2431
+ <action id="{list}" op="move|delete|flag|trash|tag|update" tag="{id}" l="..."/>
2432
+ </ContactActionRequest>
2433
+
2434
+ <ContactActionResponse>
2435
+ <action id="{list}" op="move|delete|flag|trash|tag|update"/>
2436
+ </ContactActionResponse>
2437
+
2438
+ {list} = on input, list of contacts to act on, on output, list of
2439
+ contacts that were acted on
2440
+
2441
+ for op="update", caller can specify any or all of: l="{folder}", t="{tag-id-list}", f="{flags}", color="{color}", <a> attribute list:
2442
+
2443
+ <action id="{list}" op="update" [l="{folder}"] [t="{tag-id-list}"] [f="{flags}"] [color="{color}"]>
2444
+ [<a n="fieldName">fieldValue</a>]*
2445
+ </action>
2446
+
2447
+ See <ItemActionRequest> for more details.
2448
+
2449
+ ----------
2450
+
2451
+ <ImportContactsRequest ct="{content-type}" [l="{folder-id}"] [csvfmt="{csv-format}"] [csvlocale="{csv-locale}"]>
2452
+ <content [aid="{attach-upload-id}"]>...</content>
2453
+ </ImportContactsRequest>
2454
+
2455
+ <ImportContactsResponse>
2456
+ <cn ids="{list-of-created-ids} n="{num-imported}"/>
2457
+ </ImportContactsResponse>
2458
+
2459
+ {content-type} = only currently supported content type is "csv"
2460
+ {folder-id} = optional folder id to import contacts into
2461
+
2462
+ {attach-upload-id} = attachment id from upload server. If specified, then body of content is ignored.
2463
+ {csv-format} = the format of csv being imported. when it's not defined Zimbra
2464
+ format is assumed. the supported formats are defined in
2465
+ $ZIMBRA_HOME/conf/zimbra-contact-fields.xml
2466
+ {csv-locale} = The locale to use when there are multiple {csv-format} locales defined. When it is not
2467
+ specified, the {csv-format} with no locale specification is used.
2468
+
2469
+ TODO: should have an option on import that matches email addresses to existing contacts, and updates/ignores them.
2470
+
2471
+ ----------
2472
+
2473
+ <ExportContactsRequest ct="{content-type}" [l="{folder-id}"] [csvfmt="{csv-format}"] [csvlocale="{csv-locale}"] [csvsep="{csv-delimiter}"]/>
2474
+
2475
+ <ExportContactsResponse>
2476
+ <content>...</content>
2477
+ </ExportContactsResponse>
2478
+
2479
+ {content-type} = currently, the only supported content type is "csv" (comma-separated values)
2480
+ {folder-id} = optional folder id to export contacts from
2481
+ {csv-format} = optional csv format for exported contacts. the supported formats
2482
+ are defined in $ZIMBRA_HOME/conf/zimbra-contact-fields.xml
2483
+ {csv-locale} = The locale to use when there are multiple {csv-format} locales defined. When it is not
2484
+ specified, the {csv-format} with no locale specification is used.
2485
+ {csv-delimiter} = optional delimiter to use in the resulting csv file
2486
+
2487
+ ----------
2488
+
2489
+ EXAMPLE:
2490
+
2491
+ <SearchRequest>
2492
+ <query>is:unread</query>
2493
+ </SearchRequest>
2494
+
2495
+ <SearchResponse hits="2" offset="...">
2496
+ <c id="12344" n="2" d="10023420023" t="1,12" f="1">
2497
+ <e p="Roland Schemers" a="schemers@example.zimbra.com" d="Roland"/>
2498
+ <e p="Dan Karp" a="dan@example.zimbra.com" d="Dan"/>
2499
+ <su>Speaking of animals</su>
2500
+ <fr>I am still looking for my monkey!</fr>
2501
+ </c>
2502
+ <c id="456" n="2" d="10023420023" t="1,12" a="1">
2503
+ <e p="Roland Schemers" a="schemers@example.zimbra.com" d="Roland"/>
2504
+ <e p="Ross Dargahi" a="ross@example.zimbra.com" d="Ross"/>
2505
+ <su>phone numbers</su>
2506
+ <fr>(650) 123-4567</fr>
2507
+ </c>
2508
+ </SearchResponse>
2509
+
2510
+ EXAMPLE:
2511
+
2512
+ <GetConvRequest>
2513
+ <c id="12345">
2514
+ <m id=""9845"/>
2515
+ </c>
2516
+ </GetConvRequest>
2517
+
2518
+ <GetConvResponse>
2519
+ <c id="12345" t="1,12" n="2">
2520
+ <su>Speaking of animals</su>
2521
+ <m id="123445" f="1" s="1234" d="10002323">
2522
+ <e p="Dan Karp" a="dan@example.zimbra.com"/>
2523
+ <fr>This is the fragment</fr>
2524
+ </m>
2525
+ <m id="9845" a="1" s="128981" d="10002323">
2526
+ <e t="f" p="Roland Schemers" a="schemers@example.zimbra.com"/>
2527
+ <e t="t" p="Dan Karp" a="dan@example.zimbra.com"/>
2528
+ <fr>This is another frag</fr>
2529
+ <mp part="" ct="multipart/mixed">
2530
+ <mp part="1" ct="text/plain" body=1">
2531
+ <content>This is another frag that is part of a bigger
2532
+ message. blah blah blah</content>
2533
+ </mp>
2534
+ <mp part="2" ct="message/rfc822">
2535
+ <mp part="2.1" ct="multipart/mixed">
2536
+ <mp part="2.1.1" ct="text/plain" name="README.txt" cd="attachment" filename="README.txt"/>
2537
+ <mp part="2.1.2" ct="image/jpeg" name="shot1.jpg" cd="inline" filename="shot1.jpg"/>
2538
+ </mp>
2539
+ </mp>
2540
+ </mp>
2541
+ </m>
2542
+ </c>
2543
+ </GetConvResponse>
2544
+
2545
+ EXAMPLE:
2546
+
2547
+ <GetMsgRequest>
2548
+ <m id="9845"/>
2549
+ </GetMsgRequest>
2550
+
2551
+ <GetMsgResponse>
2552
+ <m id="9845" a="1" s="128981" d="10002323">
2553
+ <e t="f" id="1" p="Roland Schemers" a="schemers@example.zimbra.com"/>
2554
+ <e t="t" id="2" p="Dan Karp" a="dan@example.zimbra.com"/>
2555
+ <su>Speaking of animals</su>
2556
+ <fr>This is another frag</fr>
2557
+ <mp part="" ct="multipart/mixed"/>
2558
+ <mp part="1" ct="text/plain" body="1"/>
2559
+ <content>This is another frag that is part of a bigger
2560
+ message. blah blah blah</content>
2561
+ </mp>
2562
+ <mp part="2" ct="message/rfc822"/>
2563
+ <mp part="2.1" ct="multipart/mixed"/>
2564
+ <mp part="2.1.1" ct="text/plain"/>
2565
+ <mp part="2.1.2" ct="text/plain" name="README.txt" cd="attachment" filename="README.txt"/>
2566
+ <mp part="2.1.3" ct="image/jpeg" name="shot1.jpg" cd="inline" filename="shot1.jpg"/>
2567
+ </mp>
2568
+ </mp>
2569
+ </mp>
2570
+ </m>
2571
+ </GetMsgResponse>
2572
+
2573
+ EXAMPLE:
2574
+
2575
+ <mail:BrowseRequest xmlns:mail="urn:zimbraMail">
2576
+ <query>from:roland</query>
2577
+ <browseBy>attachments</browseBy>
2578
+ </mail:BrowseRequest>
2579
+
2580
+ <mail:BrowseResponse xmlns:mail="urn:zimbraMail">
2581
+ <bd>application/pdf</bd>
2582
+ <bd>application/msword</bd>
2583
+ <bd>application/vnd.ms-powerpoint</bd>
2584
+ <bd>image/jpeg</bd>
2585
+ <bd>application/octet-stream</bd>
2586
+ <bd>text/plain</bd>
2587
+ <bd>image/gif</bd>
2588
+ <bd>message/rfc822</bd>
2589
+ </mail:BrowseResponse>
2590
+
2591
+ -----------------------
2592
+
2593
+ <NoOpRequest [wait='1' [delegate='0']] [limitToOneBlocked='1'] [timeout="msecs to wait"]/>
2594
+
2595
+ <NoOpResponse [waitDisallowed="1"]/>
2596
+
2597
+ A request that does nothing and always returns nothing. Used to keep a session alive, and return
2598
+ any pending notifications.
2599
+
2600
+ If "wait" is set, and if the current session allows them, this request
2601
+ will block until there are new notifications for the client. Note
2602
+ that the soap envelope must reference an existing session that has
2603
+ notifications enabled, and the notification sequencing number should
2604
+ be specified.
2605
+
2606
+ If "wait" is set, the caller can specify whether notifications on
2607
+ delegate sessions will cause the operation to return. If "delegate"
2608
+ is 0, delegate mailbox notifications will be ignored. The default is 1.
2609
+
2610
+ Some clients (notably browsers) have a global-limit on the number of
2611
+ outstanding sockets...in situations with two App Instances connected
2612
+ to one Zimbra Server, the browser app my appear to 'hang' if two app
2613
+ sessions attempt to do a blocking-NoOp simultaneously. Since the apps
2614
+ are completely separate in the browser, it is impossible for the apps
2615
+ to coordinate with each other -- therefore the 'limitToOneBlocked'
2616
+ setting is exposed by the server. If specified, the server will only
2617
+ allow a given user to have one single waiting-NoOp on the server at a
2618
+ time, it will complete (with waitDisallowed='1') any existing
2619
+ limited hanging NoOpRequests when a new request comes in.
2620
+
2621
+ The server may reply with a "waitDisallowed" attribute on response to
2622
+ a request with wait="1". If "waitDisallowed" is true, then
2623
+ blocking-NoOpRequests (ie requests with wait="1") are *not* allowed by
2624
+ the server right now, and the client should stop attempting them.
2625
+
2626
+ The client may specifiy a custom timeout-length for their request if
2627
+ they know something about the particular underlying network. The
2628
+ server may or may not honor this request (depending on server
2629
+ configured max/min values: see LocalConfig variables
2630
+ zimbra_noop_default_timeout, zimbra_noop_min_timeout and
2631
+ zimbra_noop_max_timeout)
2632
+
2633
+ -----------------------
2634
+
2635
+ <SetCustomMetadataRequest id="{item-id}">
2636
+ <meta section="{metadata-section-key}">
2637
+ (<a n="{key}"> {value} </a>)*
2638
+ </meta>
2639
+ </SetCustomMetadataRequest>
2640
+
2641
+ <SetCustomMetadataResponse id="{item-id}"/>
2642
+
2643
+ -- setting a custom metadata section but providing no key/value pairs
2644
+ will remove the sction from the item
2645
+
2646
+
2647
+ <GetCustomMetadataRequest id="{item-id}">
2648
+ <meta section="{metadata-section-key}"/>
2649
+ </GetCustomMetadataRequest>
2650
+
2651
+ <GetCustomMetadataResponse id="{item-id}">
2652
+ [<meta section="{metadata-section-key}">
2653
+ (<a n="{key}"> {value} </a>)*
2654
+ </meta>]
2655
+ </GetCustomMetadataResponse>
2656
+
2657
+ ---------------------------
2658
+
2659
+ <SetMailboxMetadataRequest>
2660
+ <meta section="{metadata-section-key}">
2661
+ (<a n="{key}">{value}</a>)*
2662
+ </meta>
2663
+ </SetMailboxMetadataRequest>
2664
+
2665
+ <SetMailboxMetadataResponse/>
2666
+
2667
+ -- setting a mailbox metadata section but providing no key/value pairs
2668
+ will remove the section from mailbox metadata
2669
+ -- empty value not allowed
2670
+ -- {metadata-section-key} must be no more than 36 characters long and must be
2671
+ in the format of {namespace}:{section-name}. currently the only valid
2672
+ namespace is "zwc".
2673
+
2674
+ <ModifyMailboxMetadataRequest>
2675
+ <meta section="{metadata-section-key}">
2676
+ (<a n="{key}">{value}</a>)+
2677
+ </meta>
2678
+ </ModifyMailboxMetadataRequest>
2679
+
2680
+ <ModifyMailboxMetadataResponse/>
2681
+
2682
+ -- modify request must contain one or more key/value pairs
2683
+ -- existing keys' values will be replaced by new values
2684
+ empty or null value will remove a key
2685
+ -- new keys can be added
2686
+
2687
+ <GetMailboxMetadataRequest>
2688
+ <meta section="{metadata-section-key}"/>
2689
+ </GetMailboxMetadataRequest>
2690
+
2691
+ <GetMailboxMetadataResponse>
2692
+ <meta section="{metadata-section-key}">
2693
+ (<a n="{key}">{value}</a>)*
2694
+ </meta>
2695
+ </GetMailboxMetadataResponse>
2696
+
2697
+ ---------------------------
2698
+
2699
+ <GetRulesRequest>
2700
+ <SaveRulesRequest>
2701
+
2702
+ These APIs have been replaced with <GetFilterRulesRequest> and <ModifyFilterRulesRequest>,
2703
+ which offer improved ease of use and error handling. The old APIs will continue
2704
+ to work in ZCS 6.0, and will be removed in the next major release.
2705
+
2706
+ ---------------------------
2707
+
2708
+ <GetFilterRulesRequest/>
2709
+
2710
+ <GetFilterRulesResponse>
2711
+ <filterRules>
2712
+ <filterRule name="{rule-name}" [active="{0|1}"]>*
2713
+ <filterTests condition="{allof | anyof"}>
2714
+ {test}
2715
+ [test]
2716
+ ...
2717
+ </filterTests>
2718
+ <filterActions>
2719
+ {action}
2720
+ [action]
2721
+ ...
2722
+ </filterActions>
2723
+ </filterRule>
2724
+ </filterRules>
2725
+ </GetFilterRulesResponse>
2726
+
2727
+
2728
+ <ModifyFilterRulesRequest>
2729
+ <filterRules> ... </filterRules>
2730
+ </ModifyFilterRulesRequest>
2731
+
2732
+ <ModifyFilterRulesResponse/>
2733
+
2734
+ * Default value for "active" is 1.
2735
+
2736
+ Tests:
2737
+
2738
+ <headerTest header="{comma-separated-header-names}" stringComparison="{type}" [caseSensitive="{0|1}"] value="{value}" />
2739
+ <headerExistsTest header="{header-name}" />
2740
+ <mimeHeaderTest header="{header-name}" stringComparison="{type}" [caseSensitive="{0|1}"] value="{value}" />
2741
+ <sizeTest numberComparison="{over|under}" s="{size}" />
2742
+ <dateTest dateComparison="{before|after}" d="{date}" />
2743
+ <bodyTest [caseSensitive="{0|1}"] value="{value}" />
2744
+ <attachmentTest/>
2745
+ <addressBookTest header="{header-name}" folderPath="{folder-path}" />
2746
+ <inviteTest>
2747
+ <method>{method}</method>+
2748
+ </inviteTest>
2749
+ <currentTimeTest dateComparison="{before|after}" d="time-in-HHmm-format}" />
2750
+ <currentDayOfWeekTest value="comma-separated-day-of-week-indices" />
2751
+
2752
+ Each test has the following optional attributes:
2753
+ * "negative": specifies a "not" condition for that test
2754
+ * "index": specifies a guaranteed order for the test and action elements
2755
+
2756
+ Actions:
2757
+
2758
+ <actionKeep />
2759
+ <actionDiscard />
2760
+ <actionFileInto folderPath="{folder-path}" />
2761
+ <actionTag tagName="{tag-name}" />
2762
+ <actionFlag flagName="{flag}" />
2763
+ <actionRedirect a="{email-address}" />
2764
+ <actionStop />
2765
+ <actionReply>
2766
+ <content>{body-template}</content>
2767
+ </actionReply>
2768
+ <actionNotify a="email-address" [su="subject-template"] [maxBodySize="{num-bytes}"] [origHeaders="{comma-separated-header-names}|*"]>
2769
+ <content>{body-template}</content> ?
2770
+ </actionNotify>
2771
+
2772
+ Each action has an optional "index" attribute which specifies a guaranteed order
2773
+ for the action elements.
2774
+
2775
+ stringComparison values: is, contains, matches
2776
+ numberComparison values: over, under
2777
+ dateComparison values: before, after
2778
+ size values are in bytes (no suffix), kilobytes (50K), megabytes (50M) or gigabytes (2G)
2779
+ flag values: flagged, read
2780
+ <dateTest>: date values are are truncated to the day. Hours, minutes, and seconds are ignored.
2781
+ index is an integer, used to maintain the order of filter tests and actions.
2782
+ method values: anyrequest, anyreply, publish, request, reply, add, cancel, refresh,
2783
+ counter, declinecounter. anyrequest matches publish, request, add, cancel,
2784
+ declinecounter. anyreply matches reply, refresh, counter. If no methods are
2785
+ specified, the test returns true for all invites.
2786
+ <mimeHeaderTest>: behaves just like <headerTest>, but matches headers on
2787
+ all MIME parts, instead of just the top-level headers.
2788
+ <currentDayOfWeekTest>: 0=Sunday, 6=Saturday
2789
+ body-template/subject-template: Can contain variables such as ${SUBJECT}, ${TO}, ${CC}, etc
2790
+ (basically ${any-header-name}; case not important), plus ${BODY} (text body of the message).
2791
+ origHeaders: Specifies list of headers to be copied from the original message to the notification message.
2792
+ Value "*" implies that all headers need to be copied.
2793
+
2794
+ ---------------------------
2795
+
2796
+ <ApplyFilterRulesRequest>
2797
+ <filterRules>
2798
+ <filterRule name="{name}"/>+
2799
+ </filterRules>
2800
+ [<m ids="{msg-id-list}"/>]
2801
+ [<query>{query-string}</query>]
2802
+ </ApplyFilterRulesRequest>
2803
+
2804
+ <ApplyFilterRulesResponse>
2805
+ <m ids="{msg-id-list}"/>
2806
+ </ApplyFilterRulesResponse>
2807
+
2808
+ Applies one or more filter rules to messages specified by a comma-
2809
+ separated ID list, or returned by a search query. One or the other
2810
+ can be specified, but not both. Returns the list of ids of
2811
+ existing messages that were affected.
2812
+
2813
+ Note that redirect actions are ignored when applying filter rules
2814
+ to existing messages.
2815
+
2816
+ --------------------------
2817
+
2818
+ Corresponding API for outgoing/sent email filters (message structure same as above):
2819
+
2820
+ <GetOutgoingFilterRulesRequest/>
2821
+
2822
+ <GetOutgoingFilterRulesResponse>
2823
+ ...
2824
+ </GetOutgoingFilterRulesResponse>
2825
+
2826
+
2827
+ <ModifyOutgoingFilterRulesRequest>
2828
+ ...
2829
+ </ModifyOutgoingFilterRulesRequest>
2830
+
2831
+ <ModifyOutgoingFilterRulesResponse/>
2832
+
2833
+
2834
+ <ApplyOutgoingFilterRulesRequest>
2835
+ ...
2836
+ </ApplyOutgoingFilterRulesRequest>
2837
+
2838
+ <ApplyOutgoingFilterRulesResponse>
2839
+ ...
2840
+ </ApplyOutgoingFilterRulesResponse>
2841
+
2842
+ --------------------------
2843
+
2844
+ Synchronization:
2845
+
2846
+ *** PLEASE SEE sync.txt FOR SYNC-RELATED DOCUMENTATION ***
2847
+
2848
+ ---------------------------
2849
+
2850
+ <GetSpellDictionariesRequest>
2851
+
2852
+ <GetSpellDictionariesResponse>
2853
+ <dictionary>en_US</dictionary>
2854
+ ...
2855
+ </GetSpellDictionariesResponse>
2856
+
2857
+ Returns the list of dictionaries that can be used for spell
2858
+ checking.
2859
+
2860
+ ---------------------------
2861
+
2862
+ <CheckSpellingRequest [dictionary="{name}"] [ignore="{words}"]>
2863
+ [text to spell check]
2864
+ </CheckSpellingRequest>
2865
+
2866
+ <CheckSpellingResponse available="0|1">
2867
+ <misspelled word="chickun" suggestions="chicken,chocking,chucking,Chicky,checking"/>
2868
+ </CheckSpellingResponse>
2869
+
2870
+ Suggested words are listed in decreasing order of their match score.
2871
+ The "available" attribute specifies whether the server-side spell checking
2872
+ interface is available or not.
2873
+
2874
+ {name} : the optional name of the aspell dictionary that will be used to
2875
+ check spelling. If not specified, the the dictionary will be either
2876
+ zimbraPrefSpellDictionary or the account's locale, in that order.
2877
+
2878
+ {words} : comma-separated list of words to ignore just for this request.
2879
+ These words are added to the user's personal dictionary of ignore words
2880
+ stored as zimbraPrefSpellIgnoreWord.
2881
+
2882
+ ---------------------------
2883
+
2884
+ <GetAllLocalesRequest/>
2885
+
2886
+ <GetAllLocalesResponse>
2887
+ <locale id="en_US" name="English (United States)"/>
2888
+ ...
2889
+ </GetAllLocalesResponse>
2890
+
2891
+ Returns all locales defined in the system. This is the same list returned by
2892
+ java.util.Locale.getAvailableLocales(), sorted by display name (name attribute).
2893
+
2894
+ ---------------------------
2895
+
2896
+ <GetAvailableLocalesRequest/>
2897
+
2898
+ <GetAvailableLocalesResponse>
2899
+ <locale id="{locale-id}" name="{locale-name-in-preferred-locale}"/>
2900
+ ...
2901
+ </GetAvailableLocalesResponse>
2902
+
2903
+ Returns intersection of all translated locales installed on the server and the list specified in zimbraAvailableLocale.
2904
+ The locale list in the response is sorted by display name (name attribute).
2905
+
2906
+ {locale-id} : locale id. e.g. en_US
2907
+ {locale-name-in-preferred-locale} : locale name in the preferred locale
2908
+ For example, if the locale is fr_CA and the preferred locale is en_US, name will contain "French (Canada)";
2909
+ if the locale is en_US and the preferred locale is fr_CA, name will contain "anglais (Etats-Unis)"
2910
+
2911
+ The preferred locale is determined with the following precedence:
2912
+ (1) zimbraPrefLocale of the target account if it is present
2913
+ (2) Otherwise the locale specified in the Accept-Language http header if it is present
2914
+ (3) Otherwise the locale returned by Provisioning.getLocale, which uses a predefined fallback
2915
+ chain to determine the preferable locale.
2916
+
2917
+
2918
+ ---------------------------
2919
+
2920
+ <TestDataSourceRequest>
2921
+ <pop3 host="pop.myisp.com" port="110" connectionType="cleartext|ssl"
2922
+ username="mylogin" password="mypassword" leaveOnServer="true|false"/>
2923
+
2924
+ or
2925
+
2926
+ <imap host="imap.myisp.com" port="143" connectionType="cleartext|ssl"
2927
+ username="mylogin" password="mypassword"/>
2928
+ </TestDataSourceRequest>
2929
+
2930
+ or
2931
+
2932
+ <TestDataSourceRequest>
2933
+ <pop3 id="{id}" [host="pop.myisp.com"] [port="110"] [connectionType="cleartext|ssl"]
2934
+ [username="mylogin"] [password="mypassword"]/>
2935
+
2936
+ or
2937
+
2938
+ <imap id="{id}" [host="imap.myisp.com"] [port="143"] [connectionType="cleartext|ssl"]
2939
+ [username="mylogin"] [password="mypassword"]/>
2940
+ </TestDataSourceRequest>
2941
+
2942
+ <TestDataSourceResponse>
2943
+ <pop3 success="0|1" [error="Error message"]/>
2944
+
2945
+ or
2946
+
2947
+ <imap success="0|1" [error="Error message"]/>
2948
+ </TestDataSourceResponse>
2949
+
2950
+ Tests the connection to the specified data source. Does not modify
2951
+ the data source or import data. If the id is specified, uses an existing
2952
+ data source. Any values specified in the request are used in the test
2953
+ instead of the saved values.
2954
+
2955
+ ---------------------------
2956
+
2957
+ ===================
2958
+ emailAddress="changed-phoebe@google.com"
2959
+ useAddressForForwardReply="false"
2960
+ defaultSignature="95915d7a-1809-4a73-a50f-c465214fae62"
2961
+ fromDisplay="changed-from-display"
2962
+ replyToAddress="changed-replay-to-addr@google.com"
2963
+ replyToDisplay="changed-replyto-display"/>
2964
+ ==================
2965
+ <CreateDataSourceRequest/>
2966
+ <pop3 name="My POP3 Account" isEnabled="0|1" host="pop.myisp.com" port="110"
2967
+ connectionType="cleartext|ssl" username="mylogin" password="mypassword" l="{folder-id}"
2968
+ leaveOnServer="0|1" [pollingInterval="10m"]
2969
+ [emailAddress="{email-address}"]
2970
+ [useAddressForForwardReply="0|1"]
2971
+ [defaultSignature="{default-signature-id}"]
2972
+ [forwardReplySignature="{forward-reply-signature-id}"]
2973
+ [fromDisplay="{from-display}"]
2974
+ [fromAddress="{from-address}"]
2975
+ [replyToAddress="{replyto-address}"]
2976
+ [replyToDisplay="{replyto-display}"]/>
2977
+
2978
+ or
2979
+
2980
+ <imap name="My IMAP Account" isEnabled="0|1" host="imap.myisp.com" port="143"
2981
+ connectionType="cleartext|ssl" username="mylogin" password="mypassword" l="{folder-id}"
2982
+ [pollingInterval="10m"]
2983
+ [emailAddress="{email-address}"]
2984
+ [useAddressForForwardReply="0|1"]
2985
+ [defaultSignature="{default-signature-id}"]
2986
+ [fromDisplay="{from-display}"]
2987
+ [fromAddress="{from-address}"]
2988
+ [replyToAddress="{replyto-address}"]
2989
+ [replyToDisplay="{replyto-display}"]/>
2990
+ </CreateDataSourceRequest>
2991
+
2992
+ <CreateDataSourceResponse>
2993
+ <pop3 id="{id}"/>
2994
+ </CreateDataSourceResponse>
2995
+
2996
+ Creates a data source that imports mail items into the specified folder via
2997
+ the POP3 or IMAP protocol. Only one data source is allowed per request.
2998
+
2999
+ ---------------------------
3000
+
3001
+ <GetDataSourcesRequest/>
3002
+
3003
+ <GetDataSourcesResponse>
3004
+ *[<pop3 id="{id}" name="My POP3 Account" isEnabled="0|1" host="pop3.myisp.com" port="110"
3005
+ username="mylogin" l="{folder-id}" leaveOnServer="0|1" [pollingInterval="10m"]
3006
+ [emailAddress="{email-address}"]
3007
+ [useAddressForForwardReply="0|1"]
3008
+ [defaultSignature="{default-signature-id}"]
3009
+ [forwardReplySignature="{forward-reply-signature-id}"]
3010
+ [fromDisplay="{from-display}"]
3011
+ [fromAddress="{from-address}"]
3012
+ [replyToAddress="{replyto-address}"]
3013
+ [replyToDisplay="{replyto-display}"]
3014
+ [failingSince="{timestamp}">]
3015
+ [<lastError>{error message}</lastError>]
3016
+ </pop3>]
3017
+ *[<imap name="My IMAP Account" isEnabled="0|1" host="imap.myisp.com" port="143"
3018
+ connectionType="cleartext|ssl" username="mylogin" l="{folder-id}" [pollingInterval="10m"]
3019
+ [emailAddress="{email-address}"]
3020
+ [useAddressForForwardReply="0|1"]
3021
+ [defaultSignature="{default-signature-id}"]
3022
+ [forwardReplySignature="{forward-reply-signature-id}"]
3023
+ [fromDisplay="{from-display}"]
3024
+ [fromAddress="{from-address}"]
3025
+ [replyToAddress="{replyto-address}"]
3026
+ [replyToDisplay="{replyto-display}"]>
3027
+ [failingSince="{timestamp}">]
3028
+ [<lastError>{error message}</lastError>]
3029
+ </imap>]
3030
+ ...
3031
+ </GetDataSourcesResponse>
3032
+
3033
+ Returns all data sources defined for the given mailbox. For each data source,
3034
+ every attribute value is returned except password.
3035
+
3036
+ lastError: the error message from the most recent sync for this data source.
3037
+ This element is not returned if the last sync was successful.
3038
+ failingSince: if the most recent sync(s) failed, this attribute specifies
3039
+ the timestamp of the first failure. This attribute is not returned
3040
+ if the last sync was successful.
3041
+
3042
+ ---------------------------
3043
+
3044
+ <ModifyDataSourceRequest>
3045
+ *[<pop3 id="{id}" [name="My POP3 Account"] [isEnabled="0|1"] [host="pop3.myisp.com"]
3046
+ [port="110"] [connectionType="cleartext|ssl"] [username="mylogin"]
3047
+ [password="mypassword"] [l="{folder-id}"] [leaveOnServer="0|1"]
3048
+ [pollingInterval="10m"]
3049
+ [emailAddress="{email-address}"]
3050
+ [useAddressForForwardReply="0|1"]
3051
+ [defaultSignature="{default-signature-id}"]
3052
+ [forwardReplySignature="{forward-reply-signature-id}"]
3053
+ [fromDisplay="{from-display}"]
3054
+ [fromAddress="{from-address}"]
3055
+ [replyToAddress="{replyto-address}"]
3056
+ [replyToDisplay="{replyto-display}"]/>
3057
+ *[<imap name="My IMAP Account" isEnabled="0|1" host="imap.myisp.com" port="143"
3058
+ connectionType="cleartext|ssl" username="mylogin" password="mypassword" l="{folder-id}"
3059
+ [pollingInterval="10m"]
3060
+ [emailAddress="{email-address}"]
3061
+ [useAddressForForwardReply="0|1"]
3062
+ [defaultSignature="{default-signature-id}"]
3063
+ [forwardReplySignature="{forward-reply-signature-id}"]
3064
+ [fromDisplay="{from-display}"]
3065
+ [fromAddress="{from-address}"]
3066
+ [replyToAddress="{replyto-address}"]
3067
+ [replyToDisplay="{replyto-display}"]/>
3068
+ </ModifyDataSourceRequest>
3069
+
3070
+ <ModifyDataSourceResponse/>
3071
+
3072
+ Changes attributes of the given data source. Only the attributes specified in the request
3073
+ are modified. If the username, host or leaveOnServer settings are modified, the server
3074
+ wipes out saved state for this data source. As a result, any previously downloaded
3075
+ messages that are still stored on the remote server will be downloaded again.
3076
+
3077
+ ---------------------------
3078
+
3079
+ <DeleteDataSourceRequest>
3080
+ *[<dsrc [id="{data-source-id}" | name="{data-source-name}"]/>]
3081
+ *[<pop3 [id="{data-source-id}" | name="{data-source-name}"]/>]
3082
+ *[<imap [id="{data-source-id}" | name="{data-source-name}"]/>]
3083
+ ...
3084
+ </DeleteDataSourceRequest>
3085
+
3086
+ <DeleteDataSourceResponse/>
3087
+
3088
+ Deletes the given data sources. The name or id of each data source must
3089
+ be specified.
3090
+
3091
+ ---------------------------
3092
+
3093
+ <ImportDataRequest>
3094
+ *[<dsrc id="{id}"/>]
3095
+ *[<pop3 id="{id}"/>]
3096
+ *[<imap id="{id}"/>]
3097
+ ...
3098
+ </ImportDataRequest>
3099
+
3100
+ <ImportDataResponse/>
3101
+
3102
+ Triggers the specified data sources to kick off their import processes. Data import runs
3103
+ asynchronously, so the response immediately returns. Status of an import can be queried
3104
+ via the <GetImportStatusRequest> message. If the server receives an
3105
+ <ImportDataRequest> while an import is already running for a given data source,
3106
+ the second request is ignored.
3107
+
3108
+ ---------------------------
3109
+
3110
+ <GetImportStatusRequest/>
3111
+
3112
+ <GetImportStatusResponse>
3113
+ *[<pop3 id="{id}" isRunning="0|1" [success="0|1"] [error="Error message"]/>]
3114
+ *[<imap id="{id}" isRunning="0|1" [success="0|1"] [error="Error message"]/>]
3115
+ ...
3116
+ </GetImportStatusResponse>
3117
+
3118
+ Returns current status for all data sources. Status values for a data source are
3119
+ reinitialized when either (a) another import process is started or (b) when the
3120
+ server is restarted. If import has not run yet, the success and error attributes
3121
+ are not specified.
3122
+
3123
+ isRunning: Whether data is currently being imported from this data source.
3124
+ success: Whether the last import completed successfully.
3125
+ error: If the last import failed, the error message that was returned.
3126
+
3127
+ ---------------------------
3128
+
3129
+ WaitSet: scalable mechanism for listening for changes to one or more accounts
3130
+
3131
+ <CreateWaitSetRequest>
3132
+ <CreateWaitSetResponse>
3133
+ <WaitSetRequest>
3134
+ <WaitSetResponse>
3135
+ <DestroyWaitSet>
3136
+ <DestroyWaitSetResponse>
3137
+
3138
+ ***See soap-waitset.txt for WaitSet API documentation***
3139
+
3140
+ ---------------------------
3141
+
3142
+ Get account level permissions.
3143
+
3144
+ <GetPermissionRequest>
3145
+ <!-- get only the permissions for the specified rights -->
3146
+ [<ace right="{right1}"/>
3147
+ <ace right="{right2}"/>]
3148
+ </GetPermissionRequest>
3149
+
3150
+ If no <ace> elements are provided, all ACEs are returned in the response.
3151
+ If <ace> elements are provided, only those ACEs with specified rights are returned in the response.
3152
+
3153
+ <GetPermissionResponse>
3154
+ <ace right="{right}" [deny="{deny}"] gt="{grantee-type}" zid="{zimbra-id}" [d="{grantee-name}"] [pw="{password}"] [key="{accesskey}"]/>*
3155
+ </GetPermissionResponse>
3156
+
3157
+ {right} = viewFreeBusy | invite
3158
+
3159
+ {deny} = 1 | 0(default)
3160
+ if a right is specifically denied
3161
+
3162
+ {grantee-type} = the type of grantee:
3163
+ usr - Zimbra user
3164
+ grp - Zimbra group(distribution list)
3165
+ all - all authenticated users
3166
+ gst - non-Zimbra email address and password (not yet supported)
3167
+ key - external user with an accesskey
3168
+ pub - public authenticated and unauthenticated access
3169
+
3170
+ {zimbra-id} = zimbraId of the grantee
3171
+
3172
+ {grantee-name} = display name of the grantee.
3173
+ ot present if {grantee-type} is "all" or "pub"
3174
+
3175
+ {pw} = optional arguments. password when {grantee-type} is "gst" (not yet supported)
3176
+
3177
+ {key} = optional arguments. access key when {grantee-type} is "key"
3178
+
3179
+ ---------------------------
3180
+
3181
+ Grant account level permissions.
3182
+
3183
+ <GrantPermissionRequest>
3184
+ <ace right="{right}" [deny="{deny}"] gt="{grantee-type}" [zid="{zimbra-id}"] [d="{grantee-name}"] [pw="{password}"] [key="{accesskey}"]/>+
3185
+ </GrantPermissionRequest>
3186
+
3187
+ If gt is:
3188
+ usr - either zid or d is required.
3189
+ grp - either zid or d is required.
3190
+ all - zid, d, pw are ignored
3191
+ gst - zid is ignored, d is required, pw is optional
3192
+ key - zid is ignored, d is required
3193
+ pub - zid, d, pw are ignored
3194
+
3195
+ For usr and grp:
3196
+ - if zid is provided, server will lookup the entry by zid and grantee type, and d is ignored.
3197
+ - if zid is not provided and d is provided, server will lookup the grantee by name and grantee type.
3198
+ if the lookup failed, NO_SUCH_ACCOUNT/NO_SUCH_DISTRIBUTION_LIST will be thrown.
3199
+
3200
+ If gt == key:
3201
+ - if key is given, server will use that as the access key for this grant
3202
+ - if key is not given, server will generate an access key
3203
+
3204
+
3205
+ GrantPermissionResponse returns permissions that are successfully granted.
3206
+
3207
+ <GrantPermissionResponse>
3208
+ <ace right="{right}" [deny="{deny}"] gt="{grantee-type}" zid="{zimbra-id}" [d="{grantee-name}"] [pw="{password}"] [key="{accesskey}"]/>*
3209
+ </GrantPermissionResponse>
3210
+ ---------------------------
3211
+
3212
+ Revoke account level permissions.
3213
+
3214
+ <RevokePermissionRequest>
3215
+ <ace right="{right}" [deny="{deny}"] gt="{grantee-type}" [zid="{zimbra-id}"] [d="{grantee-name}"]/>*
3216
+ </RevokePermissionRequest>
3217
+
3218
+ Same notes as those for GrantPermissionRequest about identifying the grantee.
3219
+
3220
+ RevokePermissionResponse returns permissions that are successfully revoked.
3221
+
3222
+ <RevokePermissionResponse>
3223
+ <ace right="{right}" [deny="{deny}"] gt="{grantee-type}" zid="{zimbra-id}" [d="{grantee-name}"] [pw="{password}"] [key="{accesskey}"]/>*
3224
+ </RevokePermissionResponse>
3225
+
3226
+ ---------------------------
3227
+
3228
+ <CheckPermissionRequest>
3229
+ <target type="{target-type}" by="id|name">...</target>
3230
+ <right>...</right>+
3231
+ </CheckPermissionRequest>
3232
+
3233
+ {target-type} = account | calresource
3234
+
3235
+ Check if the authed user has the specified right(s) on a target.
3236
+
3237
+ If the specified target cannot be found:
3238
+ - if by is "id", throw NO_SUCH_ACCOUNT/NO_SUCH_CALENDAR_RESOURCE
3239
+ - if by is "name", return the default permission for the right.
3240
+
3241
+ e.g.
3242
+ With user1's auth token, the following checks if user1 can invite user2 and
3243
+ view user2's free/busy.
3244
+
3245
+ <CheckPermissionRequest>
3246
+ <target type="account" by="name">user2@test.com</target>
3247
+ <right>invite</right>
3248
+ <right>viewFreeBusy</right>
3249
+ </CheckPermissionRequest>
3250
+
3251
+
3252
+ <CheckPermissionResponse allow="{1|0}">
3253
+ <right allow="{1|0}">invite</right>
3254
+ <right allow="{1|0}">viewFreeBusy</right>
3255
+ </CheckPermissionResponse>
3256
+
3257
+ allow = 1 | 0
3258
+ 1: the authed user has the right on the target
3259
+ 0: the authed user does not have the right on the target
3260
+ In CheckPermissionResponse, it is the AND result of each individual result
3261
+ In each <right> element, it is the result for that right.
3262
+
3263
+
3264
+ ---------------------------
3265
+
3266
+ <GetVersionInfoRequest/>
3267
+
3268
+ <GetVersionInfoResponse>
3269
+ <info version="{version-string}" release="{release-string}" buildDate="{YYYYMMDD-hhmm}" buildHost="{host-name}"/>
3270
+ </GetVersionInfoResponse>
3271
+
3272
+ This request will return a SOAP fault if the zimbraSoapExposeVersion
3273
+ server/globalconfig attribute is set to FALSE.
3274
+
3275
+ ---------------------------
3276
+
3277
+ <GetWhiteBlackListRequest/>
3278
+
3279
+ <GetWhiteBlackListResponse>
3280
+ <whiteList>
3281
+ <addr>...</addr>+
3282
+ </whiteList>
3283
+ <blackList>
3284
+ <addr>...</addr>+
3285
+ </blackList>
3286
+ </GetWhiteBlackListResponse>
3287
+
3288
+ ----------------------------
3289
+
3290
+ <ModifyWhiteBlackListRequest>
3291
+ [<whiteList>
3292
+ <addr [op="{op}"]>...</addr>+
3293
+ </whiteList>]
3294
+ [<blackList>
3295
+ <addr [op="{op}"]>...</addr>+
3296
+ </blackList>]
3297
+ </ModifyWhiteBlackListRequest>
3298
+
3299
+ Note:
3300
+ If no <addr> is present in a list, it means to remove all addresses
3301
+ in the list.
3302
+
3303
+ e.g. remove all addresses in the white list
3304
+ <ModifyWhiteBlackListRequest>
3305
+ <whiteList/>
3306
+ </ModifyWhiteBlackListRequest>
3307
+
3308
+
3309
+ {op} = + | -
3310
+ + : add, ignored if the value already exists
3311
+ - : remove, ignored if the value does not exist
3312
+ if not present, replace the entire list with provided values.
3313
+
3314
+ Note, can't mix +/- with non-present op)
3315
+
3316
+ e.g.
3317
+ 1. replace the entire white list with "foo", "bar".
3318
+ <whiteList>
3319
+ <addr>foo</addr>
3320
+ <addr>bar</addr>
3321
+ </whiteList>
3322
+
3323
+ 2. add values "foo" and "bar" to white list
3324
+ <whiteList>
3325
+ <addr op="+">foo</addr>
3326
+ <addr op="+">bar</addr>
3327
+ </whiteList>
3328
+
3329
+ 3. remove values "foo" and "bar" from white list
3330
+ <whiteList>
3331
+ <addr op="-">foo</addr>
3332
+ <addr op="-">bar</addr>
3333
+ </whiteList>
3334
+
3335
+ 4. add "foo" and remove 'bar"
3336
+ <whiteList>
3337
+ <addr op="+">foo</addr>
3338
+ <addr op="-">bar</addr>
3339
+ </whiteList>
3340
+
3341
+ 5. mix +/- and non-present op - now allowed, INVALID_REQUEST will be thrown
3342
+ <whiteList>
3343
+ <addr op="+">foo</addr>
3344
+ <addr>bar</addr>
3345
+ </whiteList>
3346
+
3347
+
3348
+ <ModifyWhiteBlackListResponse/>
3349
+
3350
+
3351
+ ----------------------------
3352
+ <GetShareInfoRequest [includeSelf="1|0"]>
3353
+ [<grantee type="{grantee_type}" [id="{grantee-id}"] [name="{grantee-name}"]/>]
3354
+ [<owner by="{owner-by}">...</owner>]
3355
+ </GetShareInfoRequest>
3356
+
3357
+ {includeSelf} = 0 if shares owned by the requested account should not be included in the response
3358
+ 1 (default) include shares owned by the requested account
3359
+ (It might be useful to see the shares I've shared to a DL that I belong to so
3360
+ that I know I'm sharing it correctly.)
3361
+
3362
+ {grantee_type} = if <owner> is not specified: grp
3363
+ if <owner> is specified: usr | grp | pub | all | cos | dom | guest | key
3364
+
3365
+ Filters the result by the specified grantee type, only shares granted to
3366
+ the grantee type will be returned. If omitted, server will return shares
3367
+ granted to all grantee types.
3368
+
3369
+ {grantee-id} = if specified, filters the result by the specified grantee id.
3370
+
3371
+ {grantee-name} = if specified, filters the result by the specified grantee name.
3372
+
3373
+ Notes on {grantee_type}, {grantee-id}, {grantee-name}:
3374
+ - it's recommended that only one of {grantee_type}, {grantee-id}, {grantee-name} is specified.
3375
+ - if multiple are specified and they conflict, e.g. {grantee-type} is grp but
3376
+ {grantee-id} contains an account id, obviously no result will be returned because
3377
+ no grant will be matching that condition.
3378
+
3379
+ {owner-by} = name | id
3380
+ Note: In order to defend against harvest attacks this SOAP call will
3381
+ return "no shares" instead of error when an invalid user name/id is used.
3382
+
3383
+ Notes:
3384
+ - if <owner> is *not* specified, server will retrieve previously published (can only be done
3385
+ by admins) share info from entries the authed account can inherit shares from.
3386
+ e.g. all direct and indirect distribution lists the account belongs. Currently share info
3387
+ can only be published on distribution lists. Publishing of cos/domain/all/pub shares
3388
+ are not supported. Therefore those shares cannot be discovered if we go this route.
3389
+
3390
+ - if <owner> *is* specified, server will iterate through the owner's mailbox to discover all
3391
+ shares applicable to the authed user, instead of looking at any of the published share info.
3392
+ All applicable shares will be returned, including any shares that are:
3393
+ - shared with the account directly
3394
+ - shared with any group(and parent groups) the account belongs. (*is* supported)
3395
+ - shared with the cos assigned to the account. (*is* supported)
3396
+ - shared with the domain this account is in. (*is* supported)
3397
+ - shared with all authed users (i.e. all Zimbra users) (*is* supported)
3398
+ - shared with the public (*is* supported)
3399
+
3400
+
3401
+ e.g.
3402
+ 1. What folders are shared with any of the groups I belong to?
3403
+
3404
+ 1a. folders of any user
3405
+ <GetShareInfoRequest>
3406
+ <grantee type="grp">
3407
+ </GetShareInfoRequest>
3408
+
3409
+ 1b. folders of a particular user
3410
+ <GetShareInfoRequest>
3411
+ <grantee type="grp">
3412
+ <owner by="name">user1@example.com</owner>
3413
+ </GetShareInfoRequest>
3414
+
3415
+ 2. What folders does a particular user share with me?
3416
+ 2a. include all folders directly shared with me and shared
3417
+ with an entry I can inherit shares from:
3418
+ <GetShareInfoRequest>
3419
+ <owner by="name">user1@example.com</owner>
3420
+ </GetShareInfoRequest>
3421
+
3422
+ 2b. include only folders directly shared with me.
3423
+ <GetShareInfoRequest>
3424
+ <grantee type="usr">
3425
+ <owner by="name">user1@example.com</owner>
3426
+ </GetShareInfoRequest>
3427
+
3428
+ 3. Show me all folders shared directly with me by any one.
3429
+ Not yet supported.
3430
+
3431
+
3432
+ <GetShareInfoResponse>
3433
+ [<share ownerId="{owner-id}" ownerEmail={owner-email} [ownerName="{owner-display-name}"]
3434
+ folderId="{folder-id}" folderPath="{fully-qualified-path}"
3435
+ view="{default-type}" [mid="{mountpoint-id}"] rights="{rights}"
3436
+ granteeType="{grantee-type}" granteeId="{grantee-id}" granteeName="{grantee-name}" [granteeDisplayName="{grantee-display-name}">]]+
3437
+ </GetShareInfoResponse>
3438
+
3439
+ mid="{mountpoint-id}" : returned if the share is already mounted.
3440
+ contains the folder id of the mountpoint in the local mailbox.
3441
+
3442
+
3443
+ ----------------------------
3444
+
3445
+ <SendShareNotificationRequest>
3446
+ <share [l="{folder-id}"] [path="{fully-qualified-path}"]
3447
+ gt="{grantee-type}" [zid="{grantee-id}"] [d="{grantee-display-name}"]/>
3448
+ [<notes>{notes}</notes>]
3449
+ </SendShareNotificationRequest>
3450
+
3451
+ granteeType = usr | grp | guest
3452
+
3453
+ - either a l or a path must be specified
3454
+
3455
+ - if gt is usr or grp, either a zid or d must be specified.
3456
+ if gt is guest, d must be specified, zid is ignored.
3457
+
3458
+ <SendShareNotificationResponse/>
3459
+
3460
+ ----------------------------
3461
+
3462
+ <GetEffectiveFolderPermsRequest>
3463
+ <folder l="{folder-id}"/>]
3464
+ </GetEffectiveFolderPermsRequest>
3465
+
3466
+ returns the effective permissions of the specified folder
3467
+
3468
+ <GetEffectiveFolderPermsResponse>
3469
+ <folder perm="{permissions}"/>
3470
+ </GetEffectiveFolderPermsResponse>
3471
+
3472
+
3473
+ ----------------------------
3474
+
3475
+ <RankingActionRequest>
3476
+ <action op="reset|delete" [email="{email-address}"] />
3477
+ </RankingActionRequest>
3478
+
3479
+ <RankingActionResponse/>
3480
+
3481
+ reset - resets the contact ranking table for the account
3482
+ delete - delete the ranking information for the email address
3483
+
3484
+ ----------------------------
3485
+
3486
+ <ModifyZimletPrefsRequest>
3487
+ <zimlet name="{name}" presence="{enabled|disabled}"/>+
3488
+ </ModifyZimletPrefsRequest>
3489
+
3490
+ <ModifyZimletPrefsResponse>
3491
+ <zimlet name="{name}" presence="{enabled|disabled}"/>+
3492
+ </ModifyZimletPrefsResponse>
3493
+
3494
+ ----------------------------
3495
+
3496
+ <GenerateUUIDRequest/>
3497
+
3498
+ <GenerateUUIDResponse>{generated UUID}</GenerateUUIDResponse>
3499
+
3500
+ Ajax client can use this request to ask the server for help in generating a proper, globally unique UUID.
3501
+
3502
+
3503
+ -----------------------------
3504
+
3505
+ <GetDistributionListMembersRequest [limit="{limit}"] [offset="{offset}"]>
3506
+ <dl>{dl-name}</dl>
3507
+ </GetDistributionListMembersRequest>
3508
+
3509
+ <GetDistributionListMembersResponse more="{more-flag}" [total="{total}"]>
3510
+ <dlm>{member email}</dlm>+
3511
+ </GetDistributionListMembersResponse>
3512
+
3513
+ Notes:
3514
+ limit - the number of members to return (0 is default and means all)
3515
+ offset - the starting offset (0, 25, etc)
3516
+
3517
+ more-flag = true if more members left to return
3518
+ total = total number of distribution lists (not affected by limit/offset)
3519
+
3520
+ -----------------------------
3521
+
3522
+ <PurgeRevisionRequest>
3523
+ <revision id="{item-id}" ver="{revision}" [includeOlderRevisions="true|false"]/>
3524
+ </PurgeRevisionRequest>
3525
+
3526
+ <PurgeRevisionResponse/>
3527
+
3528
+ When includeOlderRevisions is set to true, the server will purge all the
3529
+ old revisions inclusive of the revision specified in the request.
3530
+
3531
+ -----------------------------
3532
+
3533
+ <SendVerificationCodeRequest a="{device-email-address}"/>
3534
+
3535
+ <SendVerificationCodeResponse/>
3536
+
3537
+ Notes: SendVerificationCodeRequest results in a random verification code being generated and sent to a device.
3538
+
3539
+
3540
+ <VerifyCodeRequest a="{device-email-address}" code="{verification-code}"/>
3541
+
3542
+ <VerifyCodeResponse success="0|1">
3543
+
3544
+ Notes: Request for validating the verification code sent to a device. After successful validation the server
3545
+ sets device email address as the value of zimbraCalendarReminderDeviceEmail account attribute.
3546
+
3547
+
3548
+ <InvalidateReminderDeviceRequest a="{device-email-address}"/>
3549
+
3550
+ <InvalidateReminderDeviceResponse/>
3551
+
3552
+ -----------------------------
3553
+
3554
+ -----------------------------