Documentation FirstSpirit SiteArchitect

Objects without permissions are not displayed, either in the left-hand nor in the right-hand part of the window. If a user is to be assigned “no permissions” for a sub-area, this must also be assigned to the “Everyone” group.

Referenced objects: **No Access** is displayed for objects to which the user has no permissions and, e.g. are integrated in input components and or are referenced to elsewhere.

Permission: “Visible”

If the “Visible” permission is granted, the user can see the tree structure in the left-hand part of the SiteArchitect window.

If this permission only is granted, the right-hand editing area remains deactivated (grayed out) and cannot be edited.

The editor needs at least the “Visible” permission for the page or section templates area in the Template Store to be able to create a new page or section in the Page Store.

Permission: “Read”

If the “Read” permission is granted, the content of the object is displayed in the right-hand edit window of SiteArchitect. If the object is, for example, a Page Store page, the content of the page and of all lower-level sections is displayed.

The “Read” permission does NOT allow the user to change this content! If the “Read” permission only is granted, it is not possible to activate the edit mode of the pages, sections, page references, and media.

The “Read” permission has dependences on other editorial permissions.

The “Visible” and “Read” permissions

FirstSpirit's security model differentiates between the editorial content and the internal project information of a FirstSpirit object (e.g., ID, UID, reference name, display name). Access to this information can be controlled using the “Visible” and “Read” permissions.

Visible: The “Visible” permission is a pure display filter which prevents the content protected in this way from being displayed in SiteArchitect. Information that is protected by the “Visible” permission is returned by the API and is suitably handled retrospectively, for example, it is hidden. If the “Visible” permission only is granted, the internal project information (ID, UID, reference name, display name of an object) is displayed to the user, but not the actual content of an object (e.g., the editorial content of a page).

Read: The “Read” permission is a form of access protection that prevents access to the data or content of the object protected in this way. Therefore, access to objects which are protected by the “Read” permission (“Read” permission is withdrawn) immediately generates a corresponding message. If the “Read” permission has been issued, the editorial content of an object is also displayed to the user.

Exemplary comparison:

“Visible” permission has been withdrawn for the medium

If the Visible permission for an object has been withdrawn (corresponds to No permission), it is not displayed in the project structure (tree view) and cannot be selected within the corresponding dialog. If objects for which the user does not have “Visible” (and “Read”) permission are referenced in an input component, neither the name nor the content of the referenced object is displayed in the component:

“Visible” permission has been set for the medium

If the Visible permission is set for an object, it is displayed in the project structure (tree view), however, the editorial content, for example, of a medium is not displayed. This content is protected from access as the “Read” permission has not been issued for the object:

“Visible” permission has been set for the medium – Display in the input component

The same also applies to the display of protected content in input components. For example, if a medium to which the user solely has “Visible” permission is selected here, the user can select the medium but the content is protected against access (“No image preview”):

“Visible” and “Read” permissions have been set for the medium

If the Visible permission and the Read permission have been set for an object, this is displayed both in the project structure (tree view) and with its editorial content.

“Visible” and “Read” permissions have been set for the medium

The same also applies to the display of protected content in input components. If, for example, a medium is to be selected here for which the user has the “Visible” permission and the “Read” permission, they can select the medium; in addition, the editorial content is displayed to them, for example, in the form of an image preview:

Permission: “Change”

If the “Change” permission is granted, the user can make changes to the object and to the object's content. The “Change” permission includes:

Renaming the object
Setting the object to edit mode
Changing the content of the object
In the Page Store this permission also relates to:
- Deleting sections
- Adding sections
- Copying sections

The “Change” permission has dependences on other editorial permissions.

Permission: “Create object”

If the “Create object” permission is granted, the user can create the following objects:

In the Page Store: pages and sections
In the Media Store: media
In the Site Store: page references and document groups

It is not possible to change the existing folder structure or menu levels. All objects can only be inserted in the existing structure.

Sections can only exist in the content area of a page. The user therefore needs the “Change” permission and not the “Create object” permission to be able to create new sections within a page.

At the same time, the user needs the permission “Visible” in the Template Store for the complete path to the desired page template to be able to create a new page.

The “Create object” permission has dependences on other editorial permissions.

Permission: “Create folder”

If the “Create folder” permission is granted, the user can insert new folders in the store structures.

In the Page Store: create new folders
In the Data Store: create new folders, add new data sources, and set filters
In the Media Store: create new folders
In the Site Store: create new menu levels

The “Create folder” permission has dependences on other editorial permissions.

Permission: “Remove object”

If the “Remove object” permission is granted, the user can delete the following objects:

In the Page Store: pages with sections
In the Data Store: entries in a data source
In the Media Store: media
In the Site Store: page references

The “Remove object” permission has dependences on other editorial permissions.

Deleted objects can be restored using the Delete icon. The editor does not require any “Create object” permissions for this, as in this case it does not involve a new object.

Permission: “Remove folder”

If the “Remove folder” permission is granted, the user can remove folders in the stores. The objects to which this permission refers are identical to the objects which can be created using the “Create folder” permission.

If a folder is deleted, all its lower-level objects are automatically removed too. For example, if folders in the Page Store are removed, all lower-level folders, pages, and sections are removed too. Of course, this only applies if the user has the “Remove” permission for all lower-level objects too.

If there are elements below a folder for which the user does not have permission to delete, these elements are retained (together with the folder as a parent node).

The “Remove folder” permission has dependences on other editorial permissions.

Permission: “Release”

If the “Release” permission is granted, the user can release changed objects.

In SiteArchitect objects are released using a workflow. Within the workflow the object is converted from the “not released” state to the “released” state. The permission to “release” relates to precisely this procedure, the conversion of the object into the “Release state”. Permission to execute the individual steps of the “Release” workflow is arranged by assigning workflow permissions .

The “Release” permission has dependences on other editorial permissions.

Permission: “Show metadata”

Metadata can be defined for each object, providing working with metadata has been configured for a project. The metadata can be maintained using forms in precisely the same way as other project content and is different in a project-specific way. A special form of metadata is, for example, user permissions, whose maintenance via metadata is explained in section Permission assignment in SiteArchitect.

If the “Show metadata” permission is granted, metadata that has already been entered is displayed to the user (for example, already assigned user permissions).

The “Show metadata” permission has dependences on other editorial permissions.

Permission: “Change metadata”

If the “Change metadata” permission is granted, the user can make changes to the content of the metadata.

The “Change metadata” permission has dependences on other editorial permissions.

Permission: “Change permissions”

If the “Change permissions” permission is granted, the user can execute the permission assignment for groups and users described in this section. It is advisable to only grant this permission to persons who are assigned the role of a project administrator. By default (in newly created projects), project administrators have got this permission.

The “Change permissions” permission has dependences on other editorial permissions.

Print version | Page start