Permissions and roles (configuration in SiteArchitect)

Editorial permissions are used to cover actions that are permitted to be carried out by individual users or groups/roles within the CXT environment, such as creating fragments and variants.

Requirement for defining permissions in the project is the configuration previously carried out for:

• access of a user to the server and project levels (see Users and roles (administration)) and
• where applicable the definition of project-specific groups
  (for the simple assignment of editorial permissions and permissions to carry out workflows).

This chapter describes the configuration for access of a user to:

• objects (editorial permissions in the project)
• actions (permissions to switch workflows, approve releases,...)

The authorization to read, create, change and delete contents in FirstSpirit CXT (“editorial permissions”) and the authorization to start and switch workflows can only be configured via permission management in FirstSpirit SiteArchitect (or via the corresponding FirstSpirit API interfaces). Configuration via FragmentCreator is not possible.

Additional documentation on this topic:

• Users and roles (administration)
• Examples on permissions configuration (best practice)
• Evaluation of permissions
• General information on permission assignment in FirstSpirit SiteArchitect (Permissions in FirstSpirit (→Documentation FirstSpirit SiteArchitect))

Special features: fragments in SiteArchitect

Fragments and variants are created and edited in FragmentCreator. In this process, each fragment is based on a project-specific fragment type (e.g. “News”, “Teaser”, etc.).

Data management

Data is stored in a regular FirstSpirit project. All fragments and variants created in FragmentCreator are visible in SiteArchitect in the “Page content” area. Variants are saved here as “page” (element of the “Page” type). All variants or pages are located in the same folder for the corresponding fragment type (“Category”, see figure below).

Configuration of fragments

Fragment types for the FragmentCreator (also “Category”) are configured as page templates (element of type “PageTemplate”) in the “Page templates” area (in SiteArchitect) (see Creating fragment types). Each fragment type has a separate folder in the “Page content” area. This folder contains the persistence of the contents that are maintained in FragmentCreator for this fragment type (see above).

Defining editorial permissions (overview)

Via SiteArchitect

The permission management for individual objects (e.g. pages) are assigned in SiteArchitect via the Extras / Change permissions (context menu), both for individual users and for groups of users.

The following editorial permissions can be configured:

• Visible
• Read
• Change
• Create object
• Create folder
• Remove object
• Remove folder
• Release
• Show metadata
• Change metadata
• Change permissions

There is also the option to remove all permissions from an object by selecting the option:

• No permissions

Under Best Practice, permissions configuration are mapped to concrete actions in FragmentCreator (e.g. for creating fragments).

For more information on editorial permissions, see Editorial permissions (→Documentation FirstSpirit SiteArchitect).

Inheritance of editorial permissions

Editorial permissions always affect the object on which they were defined and are inherited by all objects assigned underneath that object within the tree structure.

When opening a fragment project in SiteArchitect, there are several special features (in comparison to traditional FirstSpirit projects). Considerably fewer areas are used and this also makes the permissions configuration for a fragment project much easier:

Area “Page content”:

• Each fragment type has a separate “folder” in the “Page content” area.
• Variants are saved as “pages” in the “Page content” area (underneath the folder for the corresponding fragment type in each case).

Templates: Only individual subareas are required from the “Templates” area.

• “Page templates” area: New fragment types (e.g.: News, Contact, ...) are used to create and configure via a “Page template” in the templates area.
• The “Workflows” and “Scripts” areas are required for executing actions (e.g. release, delete) in FragmentCreator.

All other areas (data sources, media, structure) are not required in FragmentCreator and can be hidden.

To define editorial permissions for the contents of a fragment project, it is therefore sufficient to define the permissions once on the top level of the (page) store. The permissions defined there automatically affect the entire store. An editor also requires at least “Visible” and “Read” permissions for the page templates area to obtain access to the corresponding forms in FragmentCreator.

Example: The permissions for the “cxt_edit” group are defined on the root nodes of the store and are inherited by all subordinate objects (see figure: the permissions for the “cxt_edit” group are inherited by “Fragments”, etc.).

To deviate from the higher level permissions in subordinate areas again, new permissions can be defined at the required points (see figure: the permissions for the “cxt_edit” group are removed on the “Contacts” node).

All objects to which permissions have been explicitly assigned are indicated by the icon (only in SiteArchitect – in FragmentCreator, the permissions configuration is not visible).

Note: The symbol is only displayed in SiteArchitect if in the “View” menu, the setting “Show symbols” has been activated.

The “No permissions” option should be assigned on a store's root node level with caution as in this case the entire store is hidden, regardless of which permissions are defined on subordinate levels.

Permissions defined on subordinate levels are evaluated when these permissions have been removed on a subordinate node (e.g. on the root node of a store). This means, for example, that to create new pages or sections in the Page Store a minimum of the “Visible” permission is required in the template store for the “page templates” area, but the template store can simultaneously be entirely hidden for the editor via the “No permissions” option.

Dependencies and inconsistencies in permission assignment

Dependent permissions:
Certain permissions can only be appropriately assigned if the user or group has other permissions. For example, the “Read” permission can only be appropriately assigned if simultaneously the right “Visible” has been assigned. These dependencies are automatically taken into account.

Inconsistent permissions: can occur, for example, if

• users belong to multiple groups that may have different permissions.
• permissions that have been directly assigned to the user in SiteArchitect that do not match those of the group to which the user belongs.

In these cases, a permission is regarded as granted if it has been granted in one of the settings!

Defining permissions for workflows

Permissions to execute workflows are a special type of editorial permissions that only relate to the workflows within a project. The workflow permissions are assigned in parallel with the editorial permissions. These rights can be defined at different points:

• in the workflow in the template store itself: generally valid permissions can be configured here for starting and switching a workflow, regardless of the object on which the workflow is executed.
• on the object level: Here permissions can be assigned that are dependent on the corresponding node on which the workflow is executed.

Editorial permissions for workflows

“Visible” / “Read” permission for the workflow in the template store: In the first step, the following permissions to the workflow (via the Extras / Change permissions function (context menu)) must be set for the user or group:

• ON: Permission “Visible”
• ON: Permission “Read”
• OFF: All other permissions

If these permissions are not set, the user (or the group) cannot start the workflow.

Examples of permissions configuration of workflows are presented under Best Practice for the following groups:

• cxt_request_deletion
• cxt_authorize_deletion
• cxt_request_release
• cxt_authorize_release

If a workflow uses scripts, the user or group must also have the “Visible” and “Read” permissions for these scripts.

Editorial permissions for content

Editorial permissions on objects level (Page Store): If changes to an object are made via a workflow - such as deleting objects - the user or group executing this action via a workflow must have the corresponding editorial permissions for this object (e.g. the “Remove object” permission or the “Release” permission).

Background: The group requesting the deletion of an object and the group that authorized the deletion can have different permissions. The first group therefore only requires the permission to start the workflow, and no additional editorial permissions for the objects being deleted - this permission is only required by the second group (for more details, see also Best Practice groups: cxt_deletion_request, cxt_deletion_authorization).

If scripts are used within workflows, the editorial permissions are NOT evaluated automatically. These permissions have to be suitably linked to the transition permissions within the workflow.

Workflow permissions for contents

In addition to the editorial permissions, additional permissions for starting and switching the workflow are defined for all objects. These permissions, that only relate to the execution of workflows on the object, are assigned in parallel with the editorial permissions for groups and users via the “Permission assignment” dialog box, on the “Workflow permissions” tab.

The dialog displays all workflows defined for the project, and their transitions.

The permissions to start workflows on this object are made in the top section of the “Workflow permissions” tab. If the “Permitted” checkbox is enabled, all users displayed in the “Authorized” column are permitted to start the corresponding workflow on the object.

The permissions to switch workflows are made in the lower section of the “Workflow permissions”. The permissions for implementing the workflow are defined here in detail for each step of the workflow.

The permission to start a workflow on a fragment or variant can be assigned on the root node of the Page Store or individually to the fragment folders (this means that different permissions can be granted to the different fragment types).

The permissions defined in this area overwrite the permissions that have been defined in the workflow itself (for switching a transition).

Background: On certain objects, this means that the generally valid permissions for switching are changed.

Permissions in the workflow (transitions)

Permissions to transitions in the workflow in the template store: A workflow consists of status, activities and transitions:

An activity consists of the execution of a task and triggering an action.

A status or condition always relates to an object. The current status of an object is always the result of an activity already carried out.

Transitions (shown in the editor as arrows) form the link between an activity and a status. Activities and status can have multiple incoming and/or outgoing transitions. The “Properties” dialog box (on the “Permissions” tab) can be used to configure permissions to switch a transition in the graphical workflow editor. Groups (or users) can be selected here that are to be assigned authorization to switch this transition.

For further information on this dialog, see Properties of a transition (→FirstSpirit Online Documentation).