Assign permissions

The permissions definition component appears following creation and selection in the project properties on the metadata tab of each object. Here the editor can assign permissions for the respective object.

Explanation of the component

1. Initially, metadata is not set for the permission definition component in a project. The permissions for the respective root nodes should be set first for a basic definition. The permissions for the selected nodes in the tree structure (and all nodes below it) can be defined by enabling the checkbox.
2. Each user action for which permissions (allowed, prohibited, inherited) are to be defined (e.g. “read”, “delete”), are located on a separate tab.
3. Here the individual groups are displayed in a tree structure with their sub-groups. A symbol is displayed in front of each group which indicates which permission is valid for this group and where this permission was defined or whether it is an inherited permission.
4. The valid permission for each group is displayed here in an overview list.

Assign permissions

The following permissions can be assigned:

Permissions can be changed by repeated clicked of the respective icon. If applicable, the grey symbols in the sub-tree below this are also changed. For example, if the permission of an upper group is set from “prohibited” (red cross) to “allowed” (green tick), the permission of groups below it is automatically changed from “prohibited” (grey cross) to “allowed” (grey tick). In this context, the term used is “inheritance”, i.e. the child objects inherit properties from a parent object.

If no permissions have been defined for a selected node, however, they have been for a node at a higher level, the definition of the node on which the permissions were defined is displayed. This can be recognised by the fact that a corresponding symbol cannot be seen behind the name of the selected node in the tree structure of SiteArchitect (if no other metadata has been defined, metadata are indicated by the icon in the tree structure, if configured appropriately) and the tick next to “Define Permissions” is missing in the permissions definition component.

If new groups are created, they are automatically assigned the permission of the higher-level group. The “prohibited” permission applies as a default to new groups added to the highest level.

Inheritance

Apart from group hierarchy, user permissions also have a relation to the tree structure of the FirstSpirit stores, which is also interpreted as hierarchy. Analogous to the inheritance of editorial permissions, the user permissions also always apply to the object in the tree for which they were defined and are inherited by all objects at a lower level than this object within the tree structure. This means: If there are no user permissions defined in a tree object the permissions of the parent object apply. Through this inheritance definition is is very easy, e.g. on the level of a folder, to define permissions for all pages below it.

The inheritance is defined as “not additive” – this means that a permission definition in an object overwrites all definitions “above it”.

Contradictions and problems with configuration

Contradictions can arise in hierarchical structures if permissions are explicitly defined on a node. For example, if a group's access to a Site Store folder is explicitly prohibited but its access to a lower-level folder is explicitly allowed, these defined permissions contradict each other. The plausibility of the permission assignment is not checked by the input component.

To avoid contradictions, for example with permission definition within the Site Store, the quantity of authorised groups along the tree should only be restricted but never extended, as in this case access to a “lower element in the tree” can only be achieved via the “node above”. Therefore, extending the authorisations is pointless as the high-level entry point is missing.

In the event of contradictions, the Parameter priority can be used to prioritise to which permission (i.e. either allowed or prohibited) preference should be given.

Example: If, on the root node of the Site Store, “Read” permission is explicitly prohibited for “Group 1”, it cannot be explicitly allowed for this group in the lower-level “Company” folder. This permission assignment contradicts the permission definition of the parent node. The same contradiction affects the inherited permissions of “Group 1.2”. The situation is different for “Group 1.1”: This is explicitly assigned “Read” permission in the root node and can also retain this permission in the lower-level “Company” folder. It is of course possible to constrain permissions in the lower-level element, as for “Group 2” at any time.