Permissions on types

The same permission set as used for VFS resources can also be attached to explorer types. But here the permissions have different meanings. They control which users can create, edit or view contents of the configured type.

The idea of type specific permissions

Resources in OpenCms are typed and for each type the explorer type configuration specifies where and when resources of the type are shown in OpenCms. Consider, for example, a content type configured as resource and explorer type. Here the explorer type configuration controls if and where an entry in the "Add wizard" in the traditional workplace appears, what icon is used for resources of that type, etc.

Not every type of resource is of interest for a given user. For example, a content item used for configuration may not be of interest to the normal content editor. Hence, it is useful to hide resources for some users at some places. Moreover, there may be situations where some users should be able to add existing resources of a certain type to a page, but not to add new resources. There are probably other scenarios too.

Type-specific permissions allow you to set permissions according to these scenarios.

Available permissions

Type-specific permissions are set in the explorer type configuration. The permission set is identical to the permissions assigned directly to resources. But the permissions have different meanings, or are just ignored.

Here is what the permissions (that are not ignored) mean:

Permissions on explorer types

create (c): If the permission is set, new resources of this type can be created. You can move new resources of this type to a page via the page editor or use the "Add wizard" in the traditional workplace to add new resources of the specified type.
write (w): If the permission is set, resources of this type can be edited. That means, a context menu in the workplace's editor appears for such content and you can edit contents via the ADE views.
view (v): If the permission is set, resources of this type are visible in ADE dialogs and the edit buttons appear at elements of that type. Thus you can add, move or remove elements on a page. If the view permission is not set, content of the type never appears in the ADE views. The setting has no influence in the traditional workplace, thus from the workplace's explorer you can still edit or create resources of the type, if the according other permissions are set.

Interaction of permissions

Permissions on explorer types interact differently than permissions on VFS resources. In particular:

Permissions can only be set or not set - i.e., there are just two states.
If a permission is not explicitly set for an explorer type, a default setting is used, specified in the opencms-workplace.xml in the node <defaultaccesscontrol>.
If for one user different permissions are set, allowed wins over denied.
You can set default permissions for explorer types. They overwrite the system defaults, but will be overwritten by permissions set for groups, roles or users.

Assingment of permissions

Permissions can either be assigned to single users, groups, or to roles. What the best choice is, depends on your particular situation. Possibly, the most appealing way is to set permissions dependent on roles. For example, the 'function' type (dynamic function) has the permissions set such that template developers can add new functions or edit existing ones, while normal workplace users can only view functions, i.e. add or remove them from pages.

Besides setting permissions for specific roles, groups or users, you can set default permissions for a resource type. They overwrite the system defaults, but are overwritten by all settings that are set for a role, group or user.