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 overviewThis 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


FunctionRights groupReadOnlyGroupNormal usersReportingGroupResubmissionGroup QMGroupPage-
responsible
KeyUserGroup

Read content

xxxxxxx
Edit content (draft/ proposed changes)
xxxxxx

Edit content (approved status)    








Upload attachments (draft/ proposed changes)    


xxxxxx

View usage report    




x

xxx

Configure resubmission function    




x

x

Approve content    






xx

Formal approval





x
x

Delete content (approved status)







x



Add user 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).



Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article