Our partners at Smartsheet just passed their one year anniversary of launching an integration with VMware Zimbra.  And looking back, we’ve seen a strong increase in Zimbra users embracing the online project management and collaboration app.  In fact, Smartsheet continues to be a favorite, now ranking as a “Top 5 Most Popular App” in the Zimbra Zimlet Gallery. Smartsheet now claims more than 100 joint customers with Zimbra!

For Zimbra users, Smartsheet serves as the perfect union between spreadsheets, project tools and file sharing. While most work projects take shape as a spreadsheet, they break down when you need to get others involved. There’s no way to easily track versions, much less associate notes, share files, set reminders and so forth. Smartsheet allows Zimbra users to keep the spreadsheet layout you like (and already know how to use) and gain the additional automation you need.

For Smartsheet, the momentum is exciting because Zimbra customers typically represent larger enterprise deployments and provide a higher average contribution to the bottom line. That’s smart business.

Why the uptick in momentum?
In addition to solving a real business need, here are a few other reasons that contribute to the popularity of the combined solution:

• Extends the functionality of both apps. The apps are a natural fit. You can show key project dates in Zimbra or overlay a Zimbra calendar directly to a project calendar in Smartsheet. In one click, you can import Zimbra contacts into Smartsheet for easy collaborating and sharing sheets. You can also attach documents from Zimbra briefcase to any row. The apps make each other more useful, valuable.
• Convenient access. With Smartsheet available as a tab within Zimbra, access is seamless and easy. No more having to navigate to a separate web application.
• Scales for enterprise. The combination of Smartsheet’s cloud app being “always available” with the viral nature of “sharing sheets” causes adoption to spread organically across the organization. And because it’s so flexible to set up and use, we’re seeing teams from project management to marketing, operations, HR processes, and sales pipelines, all embrace the tool. After all, everyone has work to manage.
• Provides admin controls and security safeguards required by larger organizations. Most simple web apps don’t offer provisioning controls at a centralized level. Smartsheet is “enterprise ready”, providing group tools for onboarding and monitoring users, transferring ownership of content and managing data access. Providing the ability to self-manage the deployment and ongoing maintenance of accounts and content is definitely one of the must-haves for apps to succeed in larger settings.

Thank you Zimbra community. While Smartsheet’s momentum encourages us, we understand we’ve just scratched the surface. We’re committed to working closely with Smartsheet — and all of our integration partners — to create more value for VMware Zimbra customers.

Zimbra partner Irontec of Spain recently posted a new Zimlet integration for SugarCRM in the Zimbra Gallery called “zSugar“.  This is allows end users to attach email correspondences to an Account, Contact, Opportunity or Project.

Feel free to try it out and provide your feedback, the Irontec team has deployed this with several customers already and plans on releasing an RC candidate shortly.  (Note the screen capture on the right is Spanish, but the UI is localized in English and Catalan as well).

For those less familiar with the category of CRM <—> email integrations, zSugar is similar to the Salesforce Zimlet currently available for Salesforce.com in the Zimbra Gallery which allows end users to manage their leads and customers more efficiently by not making them log in to the CRM each time records need to be updated.  (Missing correspondences in CRM records are the bane of many in sales and support, so reducing friction is critical).

SFDC Zimlet picture below:

We are pleased to announce the general availability of Zimbra Desktop 2.0!  This is a major milestone for the Zimbra team and includes significant feature and performance upgrades.  The difference between Desktop 1.0 and 2.0 is enormous thanks to the millions of downloads, thousands of forum posts, and hundreds of bugs posted by Zimbra customers and community members.

As most readers of this blog know, Zimbra Desktop is a completely unique client.  It’s the only free, cross-platform tool allowing you to meld your worlds on or offline – storing and syncing your email, calendar, contacts, files and documents in the cloud, yet having them locally accessible when on the road.  And now, in Zimbra Desktop 2.0 we have also added management of your Facebook and Twitter accounts.

Of course, Zimbra Desktop is also a valuable complement to the Zimbra Web Client and Zimbra Mobile because it provides organizations the exact same user experience on or offline, thus resulting in no productivity loss as users switch between applications.

Zimbra Desktop 2.0 builds on that success with significant advancements for End Users…

• In addition to the robust list of features already supported, we’ve added read-receipts, email filtering, tabbed compose, mandatory spell check, three-pane reading view, calendar fish-eye view, and shared access to email folders, calendars, address book and briefcase.
• Desktop already simplifies our lives by aggregating multiple email accounts (Zimbra, Yahoo! Mail, Gmail, AOL,  Hotmail, etc.). Now it adds the ability to aggregate Social accounts (Facebook, Twitter, Digg, etc.) into the same single user interface.  This is the first and only online/offline Enterprise-grade client that offers aggregation of multiple accounts for email, calendar, contacts and social. It is the true inbox for the way we work today.
• Desktop’s integrated support for the Zimlet Gallery means users have one-click access to 100+ productivity tools: Meebo, Google Translator, sticky notes, email reminders, email templates and many more.

… and for Administrators:

• Desktop 2.0 lowers help desk and IT costs by deploying the same application on Linux, Mac and Windows and by having a consistent user experience across web client, mobile client, and desktop client.
• Desktop 2.0 promotes easier back-up and restore, given all of the data and settings are backed-up in the cloud.
• Nearly limitless extensions and personalization without IT headaches through the one-click Zimlet Gallery integration.

Given the high download rates of Zimbra Desktop 2.0 beta and release candidates, we assume many Zimbra Desktop 1.0 users have already upgraded.  However, if you haven’t already installed Zimbra Desktop 2.0, existing 1.0 users should note that these significant changes have resulted in changes to the underlying database schema and installation procedures. Translation: Zimbra Desktop 2.0 will be a fresh install on your computer and trigger a re-sync – be sure to read the upgrade notes.

Again, many thanks to the community for its continued support of Desktop. See Zimbra Desktop for more details or to download Zimbra Desktop today!

Zimbra Desktop 2.0 Beta 4 has just been released. Zimbra Desktop is a free and open source email client application that gives you on- and off-line access to all your email accounts in one place. Whether you use Zimbra, Gmail, Yahoo! Mail or Microsoft Exchange, Zimbra Desktop greatly simplifies your inbox experience.

A detailed list of ZD 2.0 enhancements is available at the Zimbra Product Portal. If you are coming from an earlier ZD 2.0 Beta, one of the bigger differences you’ll notice is Zimlet support. We’ve included Zimlets like Email Reminder and everyone’s favorite Social. And you can install additional ZD compatible Zimlets via the Preferences area.

Download links are provided below. Please comment, submit feedback and questions via the Community Forums, or make use of Bugzilla to file confirmed bugs and request enhancements.

Enjoy!

Download Zimbra Desktop 2.0 Beta 4

• Windows: zdesktop_2_0_beta4_b10514_win32.msi (MD5)
• Mac OS: zdesktop_2_0_beta4_b10514_macos_intel.dmg (MD5)
• Linux: zdesktop_2_0_beta4_b10514_linux_i686.tgz (MD5)

Documentation

• Installation & Setup
• Release Notes
• FAQ

A common integration question we hear is how to handle “sign-on” between an external enterprise application and Zimbra? This scenario is when a user has signed-on to an enterprise application (for example, a Customer Relationship Management system) and that application needs to access data stored in the user mailbox hosted on a Zimbra server. To transition from the enterprise application to Zimbra, you could prompt the user to re-enter a username/password but that is not a very seamless experience. To automatically “sign-on” the user as they move between systems requires a trusted third party to “vouch for” or “assert” the user identity.

Zimbra includes a proprietary protocol for achieving this assertion, which is referred to as “Preauth“.  Preauth works by having a key that is shared between a third party application/system and Zimbra. The third party specifies the userid, a timestamp, optionally an expiration time, and an SHA-1 HMAC value computed over that data using the shared key. The Zimbra server, after successfully validating the HMAC value received in the request, redirects the user to the target Zimbra service.

There is also an alternative: SAML. SAML (Security Assertion Markup Language) can be thought of as a standard way of achieving what Zimbra Preauth protocol does.

SAML is a standard that defines an XML-based framework for exchange of security information between various business services (see http://saml.xml.org/saml-technical-overview). It is a widely adopted standard for Single Sign-On (SSO) and Federated Identity use cases. So one can envision that in scenarios such as above, a SAML assertion could be issued for the user by a central/trusted Identity Management System within the enterprise, and that assertion could be used to allow access to Zimbra. A SAML assertion typically contains security information about a subject/principal and could, for example, convey information like “This user is John Doe, he has an email address of john.doe@example.com, he was authenticated into this system using a password mechanism, at this time and date, etc”.

Example Zimbra SAML Interactions

SAML interactions/exchanges take place between entities referred to as the SAML asserting party and the SAML relying party. An asserting party is an entity that creates/issues SAML assertions. It is also sometimes called a SAML authority. A relying party is an entity that uses assertions it has received.

The picture below illustrates a setup where a user accesses a Zimbra service using a SAML assertion without any Zimbra-proprietary authentication token/cookie or Preauth. In this configuration, the Zimbra server acts as the SAML relying party.

Here’s a brief description of the interactions happening in this setup:

1. User authenticates and requests a SAML assertion from the SAML authority. [Note: This step happens outside Zimbra]
2. The SAML authority makes sure that the user has been authenticated (by some means) and then issues a SAML assertion for the user. [Note: This step happens outside Zimbra]
3. The user’s client sends a SOAP request containing an assertion identifier to the Zimbra server:

   <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope'>
       <soap:Header>
           <context xmlns='urn:zimbra'>
               <authToken type='SAML_AUTH_PROVIDER'>b07b804c-7c29-ea16-7300-4f3d6f7928ac</authToken>
           </context>
       </soap:Header>
       <soap:Body>
           <SomeRequest xmlns='urn:zimbraMail'>…</SomeRequest>
       </soap:Body>
   </soap:Envelope>
   

   [Note: The client could have alternatively sent the SAML assertion itself inside the request. Also, we are designating the auth token type as SAML_AUTH_PROVIDER, which is a custom authentication provider you must create for your environment. Later in this blog, we describe how to use Zimbra Server Extensions to implement a custom SAML Auth Provider.]

4. Zimbra server calls the SAML Authority and inquires about the assertion by passing the identifier:

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Body>
           <samlp:AssertionIDRequest ID="id-1268148042731" Version="2.0" ... >
               <samlp:AssertionIDRef>b07b804c-7c29-ea16-7300-4f3d6f7928ac</samlp:AssertionIDRef>
           </samlp:AssertionIDRequest>
       </soap:Body>
   </soap:Envelope>
   

5. The SAML Authority trusts the Zimbra server (relying party) and looks up its store of issued assertions and responds with the assertion:

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Body>
           <samlp:Response ID="id-1268148042741" ... >
               <samlp:Status>
                   <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
               </samlp:Status>
               <saml:Assertion ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac" ... >
                   <saml:Issuer>http://samlAuthority</saml:Issuer>
                   <saml:Subject>
                       <saml:NameID>user1@domain.com</saml:NameID>
                       <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
                   </saml:Subject>
                   <saml:Conditions NotBefore="2010-03-09T09:22:05Z" NotOnOrAfter="2020-12-05T09:27:05Z">
                       <saml:AudienceRestriction>
                           <saml:Audience>http://zimbra</saml:Audience>
                       </saml:AudienceRestriction>
                   </saml:Conditions>
                   <saml:AuthnStatement AuthnInstant="2010-03-09T09:22:00Z">
                       <saml:AuthnContext>
                       <saml:AuthnContextClassRef>...SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
                       </saml:AuthnContext>
                   </saml:AuthnStatement>
               </saml:Assertion>
           </samlp:Response>
       </soap:Body>
   </soap:Envelope>
   

6. Based on its trust on the SAML authority, the Zimbra server validates the SAML assertion and sends back a response to the client:

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Header>…</soap:Header>
       <soap:Body>
           <SomeResponse xmlns="urn:zimbraMail">…</SomeResponse>
       </soap:Body>
   </soap:Envelope>
   

Note: The sample messages shown above are very simplistic. In the real world, the message exchanges, especially those between the relying party and the SAML authority, are secured using TLS and/or message-level security mechanisms.

Implementing the SAML Auth Provider

The Zimbra server provides various extension points to allow extending the Zimbra server functionality (see Extending Zimbra with Server Extensions). One such extension point is the com.zimbra.cs.service.AuthProvider abstract class and an abstract sub-class the ZimbraAuthProvider. These classes know how to process/validate the Zimbra proprietary authentication tokens (or cookies).

To support SAML assertions (or tokens) within Zimbra, you can write a SamlAuthProvider class that extends AuthProvider:

public class SamlAuthProvider extends AuthProvider {

    protected SamlAuthProvider() {
        super("SAML_AUTH_PROVIDER");
    }

    protected AuthToken authToken(Element soapCtxt, Map engineCtxt) throws AuthProviderException, AuthTokenException {
        // Extract SAML assertion identifier from soap context
        // Call SAML authority and request for the SAML assertion corresponding to the identifier
        // Validate and return the SAML assertion (token)
    }
    ...
}

The SamlAuthProvider can be registered with the Zimbra server by doing the following inside the ZimbraExtension.init() method:

AuthProvider.register(new SamlAuthProvider());
AuthProvider.refresh();

Additionally, the  “zimbra_auth_provider” localconfig property needs to be modified (using the Zimbra Command Line Interface) to add your custom saml auth provider to the list of registered “zimbra auth providers”:

zmlocalconfig -e zimbra_auth_provider=SAML_AUTH_PROVIDER,Zimbra

As you can see, this is a powerful mechanism for extending Zimbra to support SAML and create a seamless Single-Sign-On experience. Although the AuthProvider class is not officially supported yet in a production environment yet, it is fine to use it in a proof of concept or an experimental project.

With over 55 million commercial Zimbra mailboxes deployed worldwide, and millions more on open source, there are many users reaping the benefits of our next-generation collaboration experience. Many factors contributed to our rapid adoption — such as integrated conversation views, tagging, sharing, powerful search, and mobility — but one of the most important is the ability to customize and extend Zimbra.

To promote extensibility, the Zimbra platform exposes powerful Theme, Data and Zimlet APIs. With these APIs, you can customize everything from branding and interface styles…to integrating external applications & services…to implementing new features. And with a vibrant Community continually using these technologies to enhance Zimbra, the customization you are looking for might already be available.

To that end, we have been busy at work leveraging new resources from our friends at VMware and are pleased to announce the new Zimbra Gallery as the destination for sharing Zimbra product extensions.

The new Gallery includes improved navigation and search capabilities so it is easier than ever to find extensions for Zimbra. The Gallery supports ratings and reviews so Community members can share their feedback and experiences. It is also much easier to share extensions, update status and highlight your work with improved extension “landing pages.”

Checkout the new Gallery at http://gallery.zimbra.com

The Gallery includes new Zimlets & Themes as well as some updated favorites such as Appointment Summary, Birthday Reminder, Email Attachment Alert, Email Downloader and Email Quotes.

Please visit the Gallery, download extensions, provide feedback and contribute. We look forward to seeing the library of available extensions in the Zimbra Gallery expand in the weeks and months to come. Enjoy!

Zimlets and the ability to extend the Zimbra Web Client is a pretty widely known capability. But did you know that Zimbra also has a framework that allows developers to extend Zimbra server-side functionality?

Zimbra Server Extensions provide a mechanism to add functionality to the server in lieu of modifying web.xml and other web server configuration files. By implementing a Server Extension, you can inject or in some cases, intercept, server-side functionality. Some examples include:

• Handling authentication requests against a user store different than the built-in Zimbra LDAP user store. Server Extensions provide a way to “plug-in” your custom authentication mechanism.
• Creating custom SOAP requests to augment the current Zimbra SOAP API.
• Registering custom mime handlers for the processing of message mime components (i.e. body, message and multipart nodes).
• Performing registration or “bootstrapping” of server-side components, such as the Microsoft Exchange Free/Busy resolver.

Getting Started

Writing an extension starts by implementing the com.zimbra.cs.extension.ZimbraExtension interface:

public interface ZimbraExtension {

    /**
     * Defines a name for the extension. It must be an identifier.
     * @return the extension name
     */
    public String getName();

    /**
     * Initializes the extension. Called when the extension is loaded.
     *
     * @throws ServiceException
     */
    public void init() throws ServiceException;

    /**
     * Terminates the extension. Called when the server is shut down.
     *
     */
    public void destroy();
}

To create your Extension:

1. Write a MyZimbraExtension class that implements the ZimbraExtension interface.
2. Create a JAR file (for example: myext.jar) and include the following attribute in the JAR manifest file:
   • Zimbra-Extension-Class: com.example.MyZimbraExtension
3. Place the myext.jar into the {zimbra_install-dir}/lib/ext/{my-ext-dir} directory.

Below are a few examples, though not an exhaustive list, of how the Server Extension framework can be used:

Custom HTTP Handlers

A Server Extension can process HTTP GET/POST/OPTIONS requests by extending the com.zimbra.cs.extension.ExtensionHttpHandler abstract class and registering the subclass in the Extension init() method.

public class MyHttpHandler implements ExtensionHttpHandler {

    // the path under which MyHandler is registered
    public String getPath() {
        return "/myext/myhandler";
    }

    // override doGet/doPost/ doOptions as needed
    ...
}

and in MyZimbraExtension.init(), do the following:

com.zimbra.cs.extension.ExtensionDispatcherServlet.register(this, new MyHttpHandler());

This would result in processing of requests at http://{my-zimbra-server-url}/service/extension/myext/myhandler being delegated to the MyHttpHandler class.

Custom SOAP Requests

If an Extension needs to support extra SOAP requests, it can do so by implementing the com.zimbra.soap.DocumentService interface and registering custom SOAP requests & operations handlers from it.

public class MyDocumentService implements DocumentService {

    /**
     * Registers <code>DocumentHandler<code> instance with document dispatcher.
     */
    public void registerHandlers(DocumentDispatcher dispatcher) {
        dispatcher.registerHandler(HelloWorldOp.REQUEST_QNAME, new HelloWorldOp());
    }
}

and in MyZimbraExtension.init(), do the following:

com.zimbra.soap.SoapServlet.addService("SoapServlet", new MyDocumentService());

Custom Authentication

If your Zimbra deployment needs to authenticate user passwords from, for example, a “home grown” authentication system and not from LDAP (which is the out-of-the-box Zimbra solution), the Extension can do so by extending the com.zimbra.cs.account.auth.ZimbraCustomAuth abstract class.  The subclass would have to implement an authenticate() method to which the plain-text password is passed as one of the arguments.

Learn More

A detailed implementation document is available at ZimbraServer/docs/extensions.txt. Now that we’ve introduced the topic, stay tuned for more information on specific Server Extension implementation examples. 

New with Zimbra Collaboration Suite 6.0 is the ability to create Zimlets that show-up as tab applications in the Zimbra Web Client.  This powerful new feature, unique to the Zimbra platform, enables partners & customers to more easily integrate third-party applications with the Zimbra Web Client. And there are already new Zimlets taking advantage of this feature, like the Social Zimlet or the BroadSoft Zimlet.

Let’s take a look at how to implement some of the basic operations of this new feature…But first, some background: the Zimbra Web Client displays multiple default applications across the top of the interface as “tabs”. These applications include (based on your deployment configuration): mail, address book, calendar, tasks, documents and briefcase. With the Zimlet Tab feature, you can add “tabs” to this array of applications.

Creating the Tab

It starts with creating the tab in your Zimlet JavaScript code. A createApp() method has been added to the ZmZimletBase class. Since all zimlets extend ZmZimletBase, to create a tab, all you need to do is call the this.createApp() method from your Zimlet. The three parameters to createApp() are:

• Tab label: the visible text “label” for the tab (for example, “My Tab”).
• Tab icon: the CSS class to use for the icon in the tab.
• Tab tool tip: the tab tool tip shown when hovering over the tab.

So creating a tab is as simple as calling the following from your Zimlet:

this._tabAppName = this.createApp("My Tab", "zimbraIcon", "A new tab app");

This method returns a unique application name for the newly created tab. You will need this unique name to manage and retrieve the different components of the tab, so it’s best to capture this return value.

Listening for Tab Application Events

Your Zimlet will also receive application events as tab applications are launched for the first time and as a user navigates around the Zimbra Web Client between tab applications. The events will be received in the ZmZimletBase.appActive() and ZmZimletBase.appLaunch() methods. By implementing these methods in your Zimlet, you will be able to know when a user launches and switches between tab applications.

Anatomy of a Tab Application

The layout of a tab application includes the following: the Tab and the Content Areas (i.e. Toolbar, Main and Overview).

The Tab

The row of tab applications across the top of the Zimbra Web Client interface is managed by an application chooser, which is represented by the Zimbra JavaScript class ZmAppChooser. The ZmAppChooser class extends ZmToolBar, making the row of tab applications basically a toolbar with buttons that look like “tabs”.

That means, after tab creation, you can manage the actual “tab” for the application as a ZmAppButton. For example, you can obtain a handle to the tab “button” through the app chooser and set, among other things, the text label & the tool tip.

var controller = appCtxt.getAppController();
var appChooser = controller.getAppChooser();

// change the tab label and tool tip
var appButton = appChooser.getButton(this._tabAppName);
appButton.setText("NEW TAB LABEL");
appButton.setToolTipContent("NEW TAB TOOL TIP");

The Content Areas

You can set the various content areas of the tab to suit your Zimlet needs. The Toolbar area is the area directly under the row of tab applications. This is typically the place where you put toolbar buttons for application control. The Overview area is located on the left-side of the page. This area typically houses a navigation tree but you can set any content you see fit. The Main area is the primary content location for the tab and can be set with whatever application content as needed.

The Toolbar Area can be obtained from the ZmZimletApp and is represented as a ZmToolBar object:

var app = appCtxt.getApp(this._tabAppName);
var toolbar = app.getToolbar();
toolbar.setContent("<b>TAB APPLICATION - TOOLBAR AREA</b>");

The Main Area can be accessed directly from the ZmZimletApp:

var app = appCtxt.getApp(this._tabAppName);
app.setContent("<b>TAB APPLICATION - MAIN AREA</b>");

The Overview Area can be obtained from the ZmZimletApp and is represented as a ZmOverview object:

var app = appCtxt.getApp(this._tabAppName);
var overview = app.getOverview();
overview.setContent("<b>TAB APPLICATION - OVERVIEW AREA</b>");

So that’s the basics of tab applications and Zimlets. As you can see, by leveraging this new Zimlet Tab feature, you will be able to create new & powerful integrations with Zimbra Collaboration Suite.

More information on implementing your own Zimlet tab application can be found in the Zimlet Developer’s Guide at:

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Introduction

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Zimlet_Tab

Zimlet Tab Examples are available at:

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Example_Zimlets#Tab_Zimlets

And checkout the Zimlet JavaScript API Reference for information on the ZmZimletBase class and tab application methods such as createApp(), appAction() and appLaunch():

http://files.zimbra.com/docs/zimlet/zcs/6.0/jsdocs/index.html

When developing a Zimlet, you are constantly making code changes and then packaging and deploying the Zimlet to be able to test those changes. This is the Zimlet development process and is done over & over again until your Zimlet is “ready” for production. An iterative development process like this that involves packaging and deploying with each code change can be quite time consuming and really impact your developer productivity.

That’s where the Zimlet Development Directory comes in.

By using the Zimlet Development Directory, you can develop your Zimlets without having to package and deploy the Zimlet with each code change. You can make your code changes directly in the Zimlet files and just refresh your browser to see the changes take affect. This will greatly reduce your development time and overall, make it much easier to build Zimlets.

To use the Zimlet Development Directory, create a _dev folder in the {zcs-install-dir}/zimlets-deployed directory. In the _dev folder, create your Zimlet folder and file structure that you can modify on the fly. It’s just that easy.

For example, say you want to create a Zimlet named “com_zimbra_myzimlet”:

1. Create the development directory:
   {zcs-install-dir}/zimlets-deployed/_dev
2. Create the Zimlet folder:
   {zcs-install-dir}/zimlets-deployed/_dev/com_zimbra_myzimlet
3. Now put your Zimlet Definition File (com_zimbra_myzimlet.xml) and whatever other resources your Zimlet needs in that directory (like JavaScript files, JSP files, Properties files, etc).
4. Make code changes to the Zimlet files as necessary and voila, just refresh your browser to see the changes take affect.

There are some limitations, however. If using Internationalization resource properties, you will need to load the Zimbra Web Client in Development Mode (i.e. with “?dev=1″ on the URL). Also, the “allowed domains” setting in the Zimlet Configuration File (config_template.xml) for the Proxy Servlet is not recognized. There is a workaround for this situation described in the Proxy Servlet Setup section of the Zimlet Developer’s Guide.

We still recommend that you package and deploy your Zimlet when you plan to go into production. But as you can see, the Zimlet Development Directory cuts-out the deploy & package development steps and is a convenient way to do iterative Zimlet development.

More information on the Zimlet Development Directory can be found in the Zimlet Developer’s Guide at:

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Dev_Environment_Setup#Zimlet_Development_Directory