Set up read/write access rights for individual pages

Modified on Wed, 10 Jul at 4:17 PM

Company philosophy: The 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 

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 pages

  • The 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, because users do not expect 'secret' content in the 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 - 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 on pages

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 proposed change of the page
  3. Open Topic preferences (three dot menu > Manage page > Topic preferences).
  4. Enter the following command: [three spaces]* Set ALLOWTOPICVIEW = [wiki-name of the group from item 1]Important: 
    - The three spaces are essential.
    - Use the ID of the wiki name, not the group name
    - If you want to use several users or groups, separate them with a comma
  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.

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 pages ).

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