Cumulus 9.1.4 was just released and includes some highly requested features including:

  • Ability to set up predefined searches for Web Client users
  • Most flexible Sites filters ever

There are also some smaller improvements, which I will discuss at the very end of this post in more detail.

Set up predefine searches for Web Client users

DAM users often need access to the same kind of assets (published whitepapers, Powerpoint templates or their personal list of todos). With the latest release of Web Client, an administrator can set up predefined searches and add direct links to those searches within the user’s main menu. The following screenshot shows the main menu of the web client with 3 custom predefined searches.


The administrator defines a short title and description for the search then selects a corresponding icon and color. For example, the color of the icon can correspond to the color of a label field used in the search. By using distinct colors and icons, the user can easily distinguish between the different searches.

When the user clicks on a predefined search, the underlying query (as defined by the admin) is executed and presented as a search result. The user can further refine the search result using filters.


Configuration of this feature is done in the Web Client Configurator of Web Server Console. Title and description links can be fully localized.


It is also possible to make a predefined search available only to certain roles or users. This enables the administrator to define different searches for different groups of users.

Most flexible Sites filters ever

As promised in my previous blog post on the 9.1.3 release , we continued and finalized our work on filters for the publishing portal Cumulus Sites. Now, an administrator has a very rich toolset to set up filters as needed.

Let’s take a look at some common use-cases. You can now group several filters using a separator. You can also control whether a separator or an individual filter is collapsed or expanded when the user accesses Sites. A common use-case is to initially only show the most common filters and hide special interest filters in a collapsed separator.

For customers from the engineering and manufacturing domain, it is very common to work with product IDs. All assets belonging to a certain product have a field with that product ID. An engineer usually knows those IDs and wants to directly filter all assets having a given product ID. Now, you can set up an input filter for that. The user enters a value and a search is performed for the related field.

A metadata field might only have a few distinct values. In such a case, the filter should provide an option for each value. On the other hand, some metadata fields might have several hundred different values. It makes no sense to show a filter with a hundred filter options in such a case. Therefore, you can now decide, per filter, if you would like to display only the most often used options.

Another option is whether a filter option should be rendered using a hierarchy. For example, if you have a filter for the modification date of files, you want to first select the year. The filter will initially only provide options for all years. After selecting a year, the filter options are replaced by the months of that year. And after selecting the month, the filter shows the individual days. We call this a hierarchical filter. You can now control for many field types whether the filter should be rendered in a hierarchy or simply listing of all values.

Finally, sometimes you have a field where the user can select multiple values. For example, you might specify in a license metadata field that a certain file might be used for print and Internet publications, but not TV ads. You can now filter such multi-select string lists.

I hope this list of use-cases shows the power of the new Sites filters. There are many more options and I invite you to dive into them to make filters as useful for your users as possible.

And a lot of minor stuff

You can now easily change the order of filters in the Web Client. In the past, there was no easy way to do it, but now you can simply move a filter in the list up and down. Filters are shown in the same order as defined in the admin UI.


For easier upgrades, we now provide the different web applications as separate downloads in the WAR format. If you have no customizations, upgrading a Cumulus web application such as Sites, Web Client or CIP will now take only a matter of minutes. These are the steps you need to follow:

  • Download the latest WAR file of the web application you want to upgrade.
  • Backup your configuration file stored inside the web application under WEB-INF/conf.
  • Delete the web application from the servlet container.
  • Deploy the new WAR file.
  • Restore the configuration file.

As you may have guessed, you can automate these steps to minimize downtime as much as possible. For the upcoming Cumulus 9.2 release, we are working on a way to store the configuration file outside of the web application container so that you don’t need to backup and restore it.

Finally, we have made a Cumulus 9.2 pre-release available to our partners so that they can test and upgrade their plugins and extensions prior to release. If everything works out as expected, Cumulus 9.2 will be released beginning of December!