In apps, content can be configured as invisible or read-only for users. This can apply to the entire app, to an element, as well as to individual content.
The rights and visibilities can be restricted at various levels in the configuration of the application:
- The entire application is visible to individual roles (1). In this case, the application is only visible to authorized roles in the left navigation bar and in the Q.wiki global search.
- For a single element, access is restricted for individual users (2). If this option is enabled, a color-coded access restriction button is displayed in the document header and the element is only visible to the defined roles. Deactivated, the element is visible for all users.
- Tip: If a single element, with e.g. critical content, is to be made visible to a defined group of people, a field of type User selection can be added to a content block and this field to the access restriction (2). Users or groups added to this field when editing the element can see and edit this element.
- The user sees the element but is not allowed to edit the content in the current workflow state (3). The user does not have the necessary permission in the current workflow state. In this case, the edit button is not available. Likewise, no tasks or attachments can be created.
- The user does not have the right to execute a continuing transition (4). Only those transitions are offered for which the current user also has the necessary right to execute.
- The user sees a content block within the edit, but cannot edit it (5). The content block has been defined as read-only in the current state. In this case, a lock icon is displayed next to the block heading.
- The user cannot see an entire content block (5). The block either contains critical information or is not relevant in the current state.
Translated with www.DeepL.com/Translator (free version)