Company philosophy: The Q.wiki aims to make organizational information transparent and accessible within the company and therefore deliberately does not focus on hiding content.


However, if content should only be visible to certain people, a new web can be created for this content and provided with the appropriate rights settings (instructions for creating new web in the Q.wiki). 


If this procedure is not possible, individual pages can also be provided with rights. Below is a list of the risks that can arise when assigning rights at the page level, followed by the technical implementation.


Risks of assigning rights on page level

  • The Q.wiki does not provide an overview of the visible protected pages, nor does it offer a global possibility to maintain the rights settings. The maintenance effort therefore increases with each additional view-protected page.
  • If the user clicks on a link of a page that is visible to him, he receives the message that he does not have the necessary rights to display it. This message is often understood as an error of the Q.wiki, because users do not expect 'secret' content in the Q.wiki. If this issue is reported to support, costs are incurred for processing by support, which are charged to the customer.
  • The rights settings are only effective for the page on which the restrictions are made. There is no inheritance of rights.
  • The assignment of rights on page level is done by the user - without technical support by Q.wiki - in a text editor. Incorrect entries can lead to the rights settings not being applied.
  • Whether rights settings are applied can only be checked by a user who does not have access to the protected page.

Procedure for assigning rights at the page level

Important: Key user rights are required to perform the following steps.


  1. Create a group with users who should see the page in the future (instructions for group management). It is important to note that in a two-step approval workflow, the page owner and a person from the 'QMGroup' must be part of the group, otherwise the workflow will no longer work. In a one-step approval workflow, the page owner is sufficient as part of the group.
  2. Open discussion state of the page
  3. Open Topic preferences (three dot menu > Manage page > Topic preferences).
  4. Enter the following command: [three spaces]* Set ALLOWTOPICVIEW = [group name from item 1]Important: The three spaces are essential.
  5. Close dialog with Save and release page

A test of the conversion is recommended and must be done with an unauthorized person. This person must not have access to the visible protected page. If the configured group name of the page setting does not correspond to the group name in the group management, all users are locked out of the page. A correction can only be made via the service and is subject to a charge.


When restricting rights, it may make sense not to direct the page through the sharing process in the future (instructions to remove the approval workflow from Q.wiki pages ).



Translated with www.DeepL.com/Translator (free version)