Detailed overview of rights concept Q.wiki

Modified on Wed, 1 Apr at 4:05 PM

In Q.wiki, you use rights groups to control what users can see and edit. This article explains which groups exist, what permissions they have, and how to assign them.

Prerequisite: You need Key User permissions to manage rights groups.

Default permissions for new users

When a new Q.wiki user is created – either manually or via Active Directory – they automatically receive the permissions of a regular user. No manual assignment is needed.

You can extend or restrict a user's permissions beyond that:

Extend permissions	Restrict permissions
Assign to `KeyUserGroup`, `QMGroup`, `ResubmissionGroup`, or `ReportingGroup`	Assign to `ReadOnlyGroup`

View and change the permissions overview

As a Key User, you can use the permissions overview to see which groups have read or write access in each module.

Permissions overview in Q.wiki showing read and write access per module

Click the gear icon on a module to adjust the permissions for a group directly.

Gear icon for changing module permissions

Dialog for editing group permissions of a module

Rights groups explained

Group	Description
Regular users	All registered users belong to this group automatically. They have all read and write permissions needed for everyday work in Q.wiki.
Page owners	Defined in the metadata of each page. They are responsible for the page content and can perform the content approval step in the approval workflow.
`KeyUserGroup`	First point of contact for regular users with questions about Q.wiki. Key Users have full editing and approval rights in the approval workflow and can access administrative tools (user management, group management, usage statistics, timeliness check).
`Unit-KeyUserGroup`	Same as `KeyUserGroup`, but limited to a single unit. First point of contact for users within that unit.
`QMGroup`	Responsible for the formal approval step in the approval workflow and for the structure and formal design of Q.wiki. Moderates process recordings. See also The seven tasks of a Q.wiki gardener (external).
`ReadOnlyGroup`	Users have read-only access. Typical use case: external auditors or customers reviewing the documentation.
`ReportingGroup`	Members can access the usage report. Key Users are automatically part of this group.
`ResubmissionGroup`	Members can configure the resubmission feature. Key Users are automatically part of this group.
`RoleManagementGroup`	If role management should be restricted to specific users, add them here. If the group is empty, all users can edit roles. Details: Role management in Q.wiki.
`UserProfileManagementGroup`	Members can edit the editable attributes of all user profiles.
`AdminGroup`	Reserved for Modell Aachen for technical setup and configuration. Can only be administered by Modell Aachen.

Functions and rights groups in the Processes module

The following table shows which functions in the Processes module are available to which rights groups.

Function	ReadOnly	Regular	Reporting	Resubmission	QM	Page owner	Key User
Read content	✓	✓	✓	✓	✓	✓	✓
Edit content (draft / change proposal)	–	✓	✓	✓	✓	✓	✓
Upload attachments (draft / change proposal)	–	✓	✓	✓	✓	✓	✓
View usage report	–	–	✓	–	–	–	✓
Configure resubmission	–	–	–	✓	–	–	✓
Content approval	–	–	–	–	–	✓	✓
Formal approval	–	–	–	–	✓	–	✓
Delete content (approved version)	–	–	–	–	–	–	✓

Assign users to a group

For a step-by-step guide, see Add or remove users from Q.wiki groups.

Notes on the Key User role

Important: Assign the Key User role carefully. We recommend training the relevant people through the Modell Aachen Academy (external).

Key Users can complete the entire approval workflow without restrictions – including both content approval and formal approval. While convenient, this carries a risk: if one person approves both steps alone, it may violate the four-eyes principle and lead to audit findings.

Our recommendations

For companies with up to 200 employees: no more than 3 Key Users
Key Users should only use their approval rights in exceptional cases, e.g. when a page owner is unavailable
Content approval should normally remain with the page owners
Formal approval is typically handled by QM (users in the QMGroup, max. 2 people)

Tips and a step-by-step guide: Formal approval – checklist.