Roles describe what an OpenCms user should and can do. A role controls the permissions of users wrt. system specific functions. Here, you can get an overview on the available roles.

What are roles for?

In a content management system users typically act in different roles. For example,

  • there is the template developer that sets up the layout of your website,
  • there are account managers that can add, remove or change user accounts,
  • there are content editors that add or edit content and maybe create new pages.

These (and also other) roles are reflected by particular permissions. OpenCms provides a whole bunch of roles that provide users with the respective permissions that fit to their role.

Which roles are available in OpenCms?

OpenCms provides various roles. Some of them are essential and maybe used in nearly every OpenCms installation. Some are only rarely of interest.

Important roles are marked with  in the following listings.

Roles that allow administrating the OpenCms system itself are only available in the root OU. All other roles are available also in sub-OUs.

Roles available only in the root OU
 Root administrator

The root administrator has all permissions in OpenCms. He automatically has all other roles - because he has the rights of these roles. The predefined user Admin is root administrator. The role is important and at least the Admin user should have this role.

Database manager

Database managers can manage module and import/export data from the database.

Workplace manager

Workplace managers can manage scheduled jobs, search indizes, property definitions, resource histories, and the workplace tools.

Usually, it suffices to have root administor(s) to administrate OpenCms. The other administrative rules are seldom of interest.

Roles available in all OUs, root and sub OUs, are the following. Note that most roles imply other roles, because the permissions for one role are a superset of these of other roles. We hint to such implications when describing the roles.

Roles available in all OUs

An administrator has all rights inside the OU. Consequently, he also has all other OU-specific roles. In particular, permissions on VFS resources are ignored for administrators, as they are VFS resource managers.

 Account manager

The account manager can manage users and groups. Account managers are automatically workplace users (and have all the roles implied by workplace users).

Project manager

The Project manager can manage projects. This role was important in older OpenCms versions, but in current versions, there usually is no need to manually add, delete or manage projects. The role implies being a workplace user, and thus also the roles implied by workplace user.

 VFS resource manager

The VFS resource manager can manage all resources in the OU. Hence, he can add, delete and alter all resources. Permission checks are ignored. For example, a resource manager may add and edit JSPs. Being a VFS resource manager involves having all the roles listed below.

 Template developer

Template developers can add and edit model pages. Note that, before OpenCms version 9.5, they could also add and edit JSPs. To allow such JSP manipulation, now the role VFS resource manager is required. Template developers automatically have all the roles listed below.

 Workplace user

A workplace user can access the traditional workplace and thus browse the VFS via the explorer. He cannot access the root site and has only very limited access to administrative tools. Workplace users automatically have all the roles listed below.

Category editor

The category editor has access only to ADE views. He can create, edit and delete categories via the sitemap editor. He automatically has all the roles listed below, except being a gallery editor.

 Gallery editor

Gallery editors have only access to ADE views. They can create or delete (image, download, ...) galleries via the sitemap editor. They have also all of the roles listed below.


An editor can create, delete and alter content on pages and change the sitemap. The role implies being an element author.

 Element author

An element author can only access the page editor (and content editors). He can create, add and edit content elements.

Roles and the Users group

For historical reasons, assigning a role to a user will automatically add the user to the Users group. Removing all roles from a user will cancel his membership in the Users group also automatically.

When you once assigned a role to a user you can remove him from the users group and he will not lose his role. This should usually not be necessary, but if you do so, keep in mind that the user is added to the Users group again when you change his role.