Mailboxes: Sharing vs. Relationships

Last year we brought shared mail folders into play to join the rest of the sharing possibilities ZCS offers, but we don’t want to overlook mentioning another feature in 5.0 that has some excellent use cases.

Let’s say you need to collaborate with an assistant (who of course manages everything for you). While sharing is recursive to sub-folders by default, depending on account structure it can mean several invites and checks to make sure everyone is seeing the proper info. Other cavets include the occasional inability for the sharee to mentally organize / conceptually visualize the sharer’s folder structure scheme, or the possible need to keep the permissions and mountpoints updated when content is moved a lot. Nothing stings like missing important information when someone shifts material into folders that aren’t actually shared according to plan; everyone can become instantly out-of-sync.

Admins know that sharing the entirety of an account can be achieved through modifyFolderGrant & createMountpoint requests. This process previously had a few downsides, like avoiding name conflicts when trying to mount the root of the account ‘all at once’ (fixed in ZCS 5.0.6+).

There are a few RFE’s in the works, such as the ability to share an entire mailbox in one click or to expose custom share roles end-user side. We’re also planning to bring clarity to your web of shares through a single-user share management UI followed by the larger share management and discovery and a new Zimlet as well, but there’s one other cool trick that’s here right now: Family Mailboxes

Don’t let the name deceive you – we’ve used the concept of parent/child relationships, yet this principle can easily apply to any primary/secondary setup such as boss/secretary, professor/assistants, or manager/co-worker/peers; where sharing of passwords is inappropriate or you don’t want another browser session open, yet you still need full control. (Wildcard sub-domains aren’t for everyone, and an additional browser can equal a bit more memory used.)

To get started via CLI (if you’re an end-user ask your admin about configuring it):
zmprov ga secondary@domain.com | grep zimbraId
zmprov ma primary@domain.com +zimbraChildAccount {zimbraIdSecondary}

We also want the secondary account visible in the accordion UI of the primary:
zmprov ma primary@domain.com +zimbraPrefChildVisibleAccount {zimbraIdSecondary}

(The primary user can also set this later from their AJAX client preferences tab.)
 
Just like how the Zimbra Desktop’s UI works, you now have access to mail, contacts, calendars, tasks, notebooks, briefcase items, and even preferences of the secondary account:



A few notes:

• As shown above – when replying from an account that’s not yours, emails include a header designating who it was really sent by & “on behalf of” is displayed. It’s also shown as unread in the sent folder of the account owner so they’re made aware of it.
• This is a little different than permissions & mountpoints – so you’ll have to use normal shares if you need access in other end-clients; it requires the AJAX interface for functionality, and currently isn’t available in the HTML web-client.
• Don’t go overboard on visible secondary accounts, our share model covers almost every situation; but as many organizations have a few crucial duos or teams who need to be on the same page every moment – this is there for those who have no time to mess with share permissions and need to manage other users, or perhaps desire complete control in a hosted family account.

To remove, simply replace the plus sign with a minus:
zmprov ma primary@domain.com -zimbraChildAccount {zimbraIdSecondary}

Have other ideas to improve work flow or make Zimbra family friendly? (Like parental mail screening, the ability for end-users to provision in HSP situations, or even admin console settings?) Then let us know below or drop in over at the community forums.