Help: Need a REST URL to return all emails (all folders) matching search criteria

Hi Zimbra Community

I'd like to issue a REST URL to query a users mail store and return a ZIP or RSS feed to all emails matching a query.

There is some information in the Wiki.
http://wiki.zimbra.com/index.php?title=User_Migration
And SVN
http://svn.sourceforge.net/viewvc/zi...=1&view=markup

For example:

Code:

---

http://[hostname]/zimbra/home/[/url][zimbra-username]/?fmt=zip&query=(from:(@zimbra.com))

---

Should return a ZIP containing all emails from zimbra.com. But it doesn't work.

This example DOES work, but only searches the Inbox folder.

Code:

---

http://[hostname]/zimbra/home/[/url][zimbra-username]/inbox.zip?query=(from:(@zimbra.com))

---

Can anyone help out?

REST currently requires a folder to root the search. Please file a bug for this enhancement. Also vote on it as this is one way we prioritize which features to work on next.

I'm pretty sure that used to work. I know I used to do things like an RSS feed for all unread items in a mailbox, across folders. I have a feeling that functionality was accidently removed during recent changes for public sharing and document support.

Please file a bug on it, and hopefully we can get it fixed in a patch release.

Quote:

---

I'd like to issue a REST URL to query a users mail store and return a ZIP or RSS feed to all emails matching a query.

---

I'd like to do a similar thing : a search based on the ID.
For example, if I want to backup the e-mail with the following ID 4144, 4145 and 4168, (*) which is the correct REST URL to write ?

For a singolar e-mail I've tried with
(THIS WORK, I KNOW)

Code:

---

http://server/zimbra/user/uname/inbox?id=4144&fmt=zip

---

but

Code:

---

http://server/zimbra/user/uname/inbox?fmt=zip&query=(id:4144)

---

or

Code:

---

http://server/zimbra/user/uname/?fmt=zip&query=(id:4144)

---

DON'T WORK even because I don't know which are the keywords (more then IS and FROM) by which build a query.

However (*) is my main issue.
10x to all for any support. :)

Quote:

---

Originally Posted by AranBenjO

I'd like to do a similar thing : a search based on the ID.
For example, if I want to backup the e-mail with the following ID 4144, 4145 and 4168, (*) which is the correct REST URL to write ?

---

Have you tried something like this?

Code:

---

http://server/zimbra/user/uname/inbox?fmt=zip&query=(item:{4144,4145,4168})

---

Quote:

---

Have you tried something like this?

---

Quote:

---

http://server/zimbra/user/uname/inbox?fmt=zip&query=(item:{4144,4145,4168})

---

Yes, but it doesn't work :(

Hi ! I've found a useful documentation on query structure here

I've another little question : with this query

http://server/zimbra/user/uname/?fmt=zip&query=(tag:tagname)

I would collect in a zip file all messages tagged with "tagname" present in ALL directories, or ALL directories except TRASH o SPAM, but I get in return all messages in INBOX tagged with "tagname" without searching recursively in INBOX.

If I have a directory structure like this (dirs with capital letter)

INBOX
...|--->Message tagged0
...|--->Message tagged0.1
...|--> TEST1
.............|--->Message tagged1
...|--->TEST2
.............|--->Message tagged2
.............|--->TEST2.1
.......................|--->Message tagged2.1
...|--->TEST3

The query will return only Message tagged{0, 0.1} without scanning recursively in all subdirs. I read (here in ISSUES/NOTES) in the past that there was a way to do this adding at the end of the url "?recursive=1" but this solution doesn't work.
If I add "&recursive=1" there is always no recursively scan.

Does anybody know a solution ?
10x

Which version are you using? There was a bug (10557) that was fixed in main and should be in the next release (not 4.0.x though). I tried off my main build and it it indeed is searching across all folders.

Quote:

---

Which version are you using?

---

This is the output of zmcontrol -v :
Release 4.0.1_GA_324.RHEL4_20060906182455 CentOS4 NETWORK edition

Which is your version ?

As I mentioned, it is off of our main branch, which is the next release that isn't a 4.0.x release. I think the current plan is before the end of the year.