Configuration of editorial permissions

Dependencies of permissions

Certain permissions can only be usefully granted if the user or group also have other permissions. The "Read" permission is, for example, not possible without the "Viewable" permission. Because, otherwise the user could theoretically read content but practically it is not possible for them to select these contents via the tree view.

If a permission is assigned, which has such a dependency to another editorial permission, FirstSpirit automatically also assigns the dependent permission.

However, "dependent" permissions can be "withdrawn" by disabling the respective checkbox. If permissions are to be reduced, the safest way is therefore to set the permissions configuration to "No Permissions" first and to then reactivate the required permissions.

Inheritance of permissions

Permissions assigned on one level in JavaClient are inherited on all levels below it. For example, if a permission is assigned at root node level of a store, this permission applies to the whole store.

For this reason, the permission "No Permissions" should be assigned with caution on store root level because the whole store will be hidden then, independent of which permissions are defined on sub-ordinate levels. If permissions are defined on sub-ordinate levels, they will be evaluated nevertheless: For example, the editor needs at least the permission "Visible" for the area page or section templates in the Template Store to be able to create a new page or section in the Page Store. At the same time, the Template Store can be hidden completely for the editor by defining the permission "No Permissions".

Which permissions are guilty for the current node can be read off in the "Inherited Permissions" area of the "Permissions Assignment" tab when the "Permissions Assignment" dialog is called.

Configuration using the "Permissions Assignment" dialog

"Permissions Assignment" dialog

On each level, it is possible to interrupt inheritance and therefore to assign individual permissions to each individual level. To do this, the "Interrupt Inheritance Hierarchy of the Permissions" checkbox must be enabled. This checkbox can be subsequently used to undo interrupted inheritance just as fast, so that the permissions then apply as for the higher level(s).

Using the Buttons "Add user" and "Add group" further permissions can be defined for a group or a user in addition to the inherited permissions.

All nodes in the tree structure at which explicit permissions have been assigned are especially labelled (by the icon or a red dot). To do this, the "Show Symbols" setting must be enabled in the "Extras" menu.

This label only shows that permissions are defined on the tab "Permission assignment" of this dialog, not if individual permissions are defined on the tab "Workflow permissions" (see Context dependent permissions for workflows).

For more detailed information on the "Permissions Assignment" dialog, please refer to the "FirstSpirit Manual for Editors".

Contradictory permissions

Contradictory permissions can result, e.g. if

• users belong to several groups, which possibly have different permissions.
• Permissions which have been directly assigned to the user in JavaClient do not match those of the group to which the user belongs.

In these cases a permission is deemed to have been assigned if it was assigned in one of the settings.

If the permissions of a group or a user are withdrawn (in the top part of the "Permissions Assignment" dialog, permissions are defined as being assigned via inheritance, however the "inheritance hierarchy of the permissions" is not interrupted and less permissions are assigned to a user or to a group in the bottom area), the withdrawn permissions are nevertheless deemed to have been issued.