Definition of permissions (CMS_INPUT_PERMISSION)
This input element allows the definition of user permissions and with this it offers a control of the visibility of content. In contrast to the editorial permissions, which control the operations that an editor can run (e.g. create / edit / delete pages), the user permissions apply to the “visitors” of the generated website. For this reason they are used in general with the metadata. The user permissions can by using this input element. The evaluation of the permissions takes place inside the project.
 |
The decision, on which elements inside the ContentCreator metadata can be set and modified, is a task of the project administrator. This can not be done by the editor. The icons to modify the metadata appear in dependence of the context in the contents or media menu or as a EasyEdit icon (see also page Metadata). |
Assigning user permissions
User permissions are usually assigned via groups. The user must be authenticated by the system, before he can be assigned to one of these groups. With the group structure, which can be created with FirstSpirit or which can be taken over from an existing system, the user permissions can be evaluated. This group structure is displayed in a tree view inside the input element.
The icons beside the groups show the user permission of the current group. Colored icons (red or green) correspond to explicitly set permissions. Grey symbols represent permissions which are inherited from a parent node (= a superior group). “group 1” and “group 2” are the parent nodes of “group 1.1” and “group 1.2” or “group 2.1” and “group 2.2” in the illustration.
User permissions can also be inherited from superior FirstSpirit elements. If – for example – user permissions have been defined for a menu item, all pages on a lower level will inherit these permissions. In this case a note will be shown inside the dialog and the user permissions are already defined.
States for groups
The following three states can be defined in the tree view:
- permission is explicitly granted (green tick, see “group 1”)
- permission is explicitly denied (red cross, see “group 2”)
- permission is inherited from the parent node and are either granted or denied depending on the definition on the parent node (grey symbol, see “group 1.1” & “group 2.1”).
The state of the user permissions can be changed by clicking the checkbox. As the permissions are inherited hierarchically within the subgroups, the grey symbols of the inherited permissions may change in the subtrees too.
|
Certain nodes are excluded from the definition of user permissions. These groups are displayed without an icon and it is not possible to set user permissions for them. |
|
The group structure displayed in the input element for user permissions are also displayed project-specific, just as in the tabs of the user permissions input element. |
Possible operations for user permissions
The configuration of user permissions allows to personalize web pages, that means the display of the page content can be – depending on the permissions of the current user – fully or partially denied (e. g. for a single section).
In general user permissions can be interpreted as the “permission to view an element”. However, in some cases “change” or “print” operations are relevant in addition to the “view” option. Therefore, various types of user permissions can be defined.
As the editorial work within ContentCreator is carried out on a generated page, the editor is therefore simultaneously also a user. So he requires user permissions to run editorial changes.
Via ContentCreator editors themselves can assign and modify user permissions for groups, and decide for which content or areas of the web page the groups get access (e. g. a “customer area” or an internal intranet of a company) is to be “granted” or “denied”.
|
The permissions, which are visible in the tabs of the input element, are defined and evaluated within the project. These are neither user permissions nor editorial permissions of FirstSpirit. |
Each of these project-specific permissions, which are to be defined within the input element for permissions, has its own tab (see figure: “read”, “write” and “execute”). So you can define for each operation explicitly, which groups are granted to perform this operation.
Managing user permissions using metadata
In general, the input element for user permissions is maintained via metadata.
|
The decision, on which elements inside the ContentCreator metadata can be set and modified (for example pages, sections, media), and the definition of the editorial permissions is a task of the project administrator. |
The input element is displayed in the respective editing dialogs of the respective metadata and the user permissions can be set or edited.
Define user permissions
Editing of user permissions can be activated by means of the checkbox “Define permissions”.
If the checkbox is disabled, the user permissions for the current node have not been defined yet. All displayed user permissions are inherited in this case from a parent node.
By activating the checkbox, the inheritance hierarchy of the permissions will be interrupted and the user permissions can be re-defined for the selected node (and all nodes below it). The inherited permissions are the basis for the new definition.
If no set permissions can be found in a parent node the input element will be empty initially.
|
For detailed information how to create and edit metadata in ContentCreator please see page Editing contents – Metadata. |