Skip to content
OpenCms documentation
OpenCms documentation

Roles in OpenCms

Each OpenCms user acts in a special role - reaching from root administrators to element authors. Learn about the available roles and the permissions implied by a role.

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 their role.

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

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

The root administrator has all permissions in OpenCms. This user automatically has all other roles, having 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 managers can manage modules and import/export data from the database.

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

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

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

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.

The VFS resource manager can manage all resources in the OU, and hence 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 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.

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

The category editor has access only to ADE views. This role can create, edit and delete categories via the sitemap editor and automatically has all the roles listed below, except that of Gallery Editor.

List editos have access to ADE views. Moreover, they can create, delete and edit contents of the integrated list type and manage lists in the lists app.

Gallery editors have only access to ADE views. They can create or delete (image, download, ...) galleries via the sitemap editor. They also have all 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.

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

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 that user's membership of the Users group, also automatically.

Once you have assigned a role to a user, you can remove that user from the users group without loss of 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 on change of role.