Inheriting user permissions within the project

Apart from group hierarchy, user permissions also have a relation to the tree structure of the FirstSpirit stores, which is also interpreted as hierarchy.

In the same way as editorial permissions are inherited, 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. That is, if there are no user permissions defined in a tree object, the permissions of the parent object apply. Through this inheritance definition is very easy, e.g., at the level of a folder, to define the 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”.

Initially, metadata is not set for the permission component in a project. The permissions for the respective root nodes should be set for a basic definition.

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 authorized groups along the tree should only be restricted but never extended, as in this case access to a “deeper element in the tree” can only be achieved via the “node above”. Therefore, extending the authorization is pointless as the higher-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 (see PERMISSION (→FirstSpirit Online Documentation)).

Contradictory hierarchical permission assignments within a project can be uncovered using a script. The component supports the linking of scripts that can be executed in a different way, e.g.

• “on clicking”, i.e., directly when a permission is defined in the component or
• via a button if a check is explicitly requested.

Checking via a script must be adjusted for the specific project by the template developer!

Permission definition with contradiction

Example of contradictory permission assignment within the Site Store:
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.