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.
In a content management system users typically act in different roles. For example,
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.
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 administrating 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. 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 managers can manage module and import/export data from the database.
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.
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.
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. 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 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. He 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. 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 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.
An element author can only access the page editor (and content editors). He 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 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.