Inheriting editorial permissions within the project

Permissions are assigned in SiteArchitect using the context menu for the objects within the individual stores. This applies to the Page Store, Site Store, Media Store, and the global pages in the Global settings.

Permissions assigned on one level in SiteArchitect 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. The permissions 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. Objects or nodes in the tree can be folders, pages, menu levels, page references or media. Permissions cannot be defined at section level. Sections can only exist within the content area of a page and therefore inherit their permissions from the higher-level page.

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”.

If you want to differ from the higher-level permissions in lower-level areas, define new permissions in the required places. However, the assignment of permissions at the highest level in the respective store is usually sufficient as these settings are automatically passed on to all other objects in this store.

All nodes in the tree structure on which permissions were explicitly assigned are indicated by the  icon. However, the permissions symbol only appears in the tree view if the “Show symbols” setting was activated in the View 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 the initial assignment of permissions within a project it is advisable to set the permissions in all stores at the level of the store root and to then redefine them if necessary in the required lower-level objects.

If permissions are withdrawn from a group or user which were defined as issued via inheritance AND if the “hierarchical inheritance of the permissions” is NOT interrupted, the withdrawn permissions are nevertheless deemed to have been granted, i.e., they are still valid.

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 SiteArchitect 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 “Permission assignment” dialog, permissions are defined as being assigned via inheritance, however the “hierarchical inheritance of 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.