Define user permissions
User permission assignment is always based on groups, since experience has shown that managment on the user level leads to major problems, e.g. for arranging representatives.
In order to structure and, therefore, facilitate permission assignment, it is assumed that groups can have a hierachical structure – i.e. a group can contain several sub-groups.
FirstSpirit helps to redefine these group structures or to import them from an existing system (e.g. LDAP).
Irrespective of its origin, the group hierarchy is presented to the editor in a tree view in which it is possible to configure the permissions. The permission component is a special input component which can be used to assign permissions on the basis of a hierarchical group definition. This permission definition exclusively refers to the runtime system and not to the editorial system, i.e. no editorial permissions. The permission component is usually used within the scope of the metadata. Nevertheless, it could also be used in the Page-Store or Content-Store.
Besides the group hierarchy, there is also a relation to the tree structure of the FirstSpirit administrations which is also interpreted as hierarchy.
The tree structure of the FirstSpirit administrations represents an inheritance relation for the permission assignment. Therefore, the following always applies: If user permissions have not yet been defined in a tree object, the permissions of the parent object apply. Due to this inheritance definition it is quite easy to define permissions for subordinated pages, e.g. on a folder layer.
The inheritance is, therefore, defined as “not additive” – i.e. the permission definition in an object overwrites all “superordinated” definitions.
Since this extremely simple inheritance model is not always suitable, there is a number of options to project-specifically define “plausibility rules” for the permission assignment (e.g. “if something is allowed for a superordinated group, it cannot be forbidden for a subgroup” or “if somebody is allowed to view an object, he/she must also be allowed to enter the superordinated subtree, otherwise he/she would never be able to reach the object”).