There's currently no rest or html public view of the mail folders so it was really misleading people - you'll have to use CLI to share with the public.
Bug 18513 - Remove "external" and "public" options from the folder share dialog was opened as a temp solution from that because the 500 errors we're just confusing users.
That currently makes it difficult to share rss feeds of mail folders, but it's a tradeoff.
RSS feed emails [SOLVED] open other user mailbox in webmail (trick while we waited for
shared mail folders)
Be sure to vote for / support ticket tag / cc watch this RFE:
Bug 16063 - Sharing Mail folder to External Guests/Public
Back on topic - so via CLI:
zmmailbox -z -m
user@domain.com modifyFolderGrant /Folder public
Though you might prefer to just keep it among ZCS users:
zmmailbox -z -m
user@domain.com modifyFolderGrant /Folder all r
(There's also group or domain.)
You could do any of the following [account <name> |group <name> |domain <name> |all |public| guest <email> <password>] followed by the permissions like r, rw, rwix, rwixd, rwixda, none, etc.
(r)ead - search, view overviews and items
(w)rite - edit drafts/contacts/notes, set flags
(i)nsert - copy/add to directory, create subfolders
action (x) - workflow actions, like accepting appointments
(d)elete - delete items and subfolders, set \Deleted flag
(a)dminister - delegate admin and change permissions
r = viewer rights
rwixd = manager rights
SOAP:
Quote:
<folder id="{folder-id}" name="{folder-name}" l="{parent-id}" [f="{flags}"] [color="{color}"] u="{unread}" n="{msg-count}" s="{total-size}" [view="{default-type}"] [url="{remote-url}"] [perm="{effective-perms}"] [rest="{rest-url}"]> [<acl> <grant perm="{rights}" gt="{grantee-type}" zid="{zimbra-id}" d="{grantee-name}" [args="{args}"]/>* </acl>]
</folder>
{folder-name} = name of folder; max length 128; whitespace is trimmed by server;
cannot contain ':', '"', '/', or any character below 0x20
{parent-id} = id of parent folder (absent for root folder)
{flags} = checked in UI (#), exclude free/(b)usy info, IMAP subscribed (*), does not (i)nherit rights from parent
{color} = numeric; range 0-127; defaults to 0 if not present; client can display only 0-7
{unread} = number of unread messages in folder
{msg-count} = number of non-subfolder items in folder
{total-size} = total size of all of non-subfolder items in folder
{default-type} = (optional) default type for the folder; used by web client to decide which view to use;
possible values are the same as <SearchRequest>'s {types}: conversation|message|contact|etc
{remote-url} = url (RSS, iCal, etc.) this folder syncs its contents to
{rest-url} = url to the folder on rest interface for rest-enabled apps (such as wiki and notebook)
{effective-perms} = for remote folders, the access rights the authenticated user has on the folder - will contain the calculated (c)reate folder permission if the user has both (i)nsert and (r)ead access on the folder
Folders can have an optional ACL set on them for sharing. If they do (and the authenticated user has (a)dminister rights on the folder), an <acl> element will be returned containing 1 or more <grant> elements, with the following attributes:
{rights} = some combination of (r)ead, (w)rite, (i)nsert, (d)elete, (a)dminister, workflow action (x)
{grantee-type} = the type of grantee: "usr", "grp", "dom" (domain), "cos",
"all" (all authenticated users), "pub" (public authenticated and unauthenticated access),
"guest" (non-Zimbra email address and password)
{grantee-name} = the display name (*not* the zimbra id) of the principal being granted rights;
optional if {grantee-type} is "all"
{args} = optional argument. password when {grantee-type} is "guest"
|
---
Misc info-
Under construction:
Bug 26763 - Tasks - Rest HTML interface Bug 26764 - Contacts - REST HTML interface
5.0.5 added:
Bug 22561 - No REST/HTML UI to list folder contents of publicly shared briefcase folder
5.0.1 included the ability to get free busy info by visiting http:// server.domain.com/home/username?fmt=freebusy which will display an aggregate HTML calendar for all the user's free-busy data. (Of course you can always choose to select "exclude this calendar when reporting free/busy times" if you wish.)
In 5.0, we added the ability to go to http:// server.domain.com/home/username/Calendar.html to see an easily readable day/week/month view. (The publisher must share the calendar specifically or publicly in order for you to see it.)