Detailed overview of rights concept Q.wiki

Modified on Thu, 12 Sep at 2:11 PM

You need key user rights to perform the following steps.

When a new Q.wiki user is created (either manually or via the Active Directory), he or she automatically receives the rights of a "normal user" without having to be assigned manually. The employee can then immediately start working in Q.wiki. However, you also have the following options for granting the user further rights or withdrawing rights.

Extension of rights:

Assignment to the KeyUserGroup
Assignment to the QMGroup
Assignment to the ResubmissionGroup
Assignment to the ReportingGroup

As a key user, you can now also see which rights your employees have in the modules via the acess overview. This means which groups have read or write permissions.

You can also make changes to the rights of your groups directly via the cogwheel of an module.

Restriction of rights:

Assignment to the ReadOnlyGroup

Description of the individual rights groups

Normal users

All registered users
All read and write permissions needed for everyday work with Q.wiki

Page owners

Are defined in the metadata of each page
Are responsible for the content of a page in the practice and in Q.wiki
Are authorised to approve the content in the approval workflow.

KeyUserGroup

Contact person for the normal users in the event of problems in operation
In the release workflow with all rights to edit in any status
In the release workflow with all rights to release each page alone - serves exclusively for administration and acceleration of the system within the framework of the releases

ReadOnlyGroup

Users have read-only rights
Example: External auditors or customers to review documentation

QMGroup

Are authorised and responsible for the formal release in the release workflow
Responsible for the structure and formal design of the Q.wiki (see also The seven tasks of a Q.wiki gardener)
Facilitators for process releases

AdminGroup

Modell Aachen User for technical setup and configuration in the background
Can only be administered by Modell Aachen

ReportingGroup

Members get access to the usage report
Members of the KeyUserGroup are automatically part of this group

ResubmissionGroup

Members of this group have the right to configure the resubmission functionality.
Members of the KeyUserGroup are automatically part of this group.

NobodyGroup

This group has no relevance for the use of Q.wiki.

RoleManagementGroup

If role management is to be reserved exclusively for certain users or groups, these must be entered here.
If the group remains empty, anyone can edit roles.
for details see Management of roles in Q.wiki

UserprofileManagementGroup

Members of this group have the right to edit the attributes of all users profiles.

Assignment of functions in the processes module to rights groups

Function	Rights group	ReadOnlyGroup	Normal users	ReportingGroup	ResubmissionGroup	QMGroup	Page- responsible	KeyUserGroup
Read content		x	x	x	x	x	x	x
Edit content (draft/ proposed changes)			x	x	x	x	x	x
Edit content (approved status)
Upload attachments (draft/ proposed changes)			x	x	x	x	x	x
View usage report				x		x	x	x
Configure resubmission function					x			x
Approve content							x	x
Formal approval						x		x
Delete content (approved status)								x

Add user groups

detailed instructions can be found here: Add users to Q.wiki groups

NOTE: Please assign the role of a key user carefully, because with many rights comes much responsibility. Please ensure that people are properly trained: Modell Aachen Academy.Key users can, for example, click through the approval workflow without "hurdles" (key users have the technical authorisation in their function to carry out both the content-related and the formal approval). However, this can lead to a disregard of the dual control principle and thus possibly also to a deviation in the audit. For companies with up to 200 employees, a maximum of 3 key users is recommended. These key users should only make use of their rights in the release workflow in exceptional cases, e.g. in the case of illness of a person responsible for a page. Otherwise, the content-related release is the sole responsibility of the page managers. Formal approval is traditionally carried out by the QM (= user in the QM group / max. 2 persons).