Page Permissions for Knowledge Components
Creating Per-Page Permission Sets
One of the most improtant features of the SQI Knowledge Components are its flexible Access Control systems. Before getting started with per-page permissions, please read through Basic Permissions for Knowledge Components to get an overview of how ACLs are structured and processed.
Default Page ACLs
For any page that does not have an ACL Declaration, the site-wide defaults are used. These defaults are generally only modified by SQI staff and have this default rule:
This means that all people who are Trusted (people who are logged in to the site with a username and password) can read the page. Everyone else (generally anonymous users) can not view the page.
Page ACL Declaration
Page ACL Declarations are defined at the top of a page with #acl followed by the ACL rules:
#acl TrustedGroup:read,write All: = Internal Topic = Example Text
The #acl directive tells the SQI Knowledge Component that the page has special ACLs. This directive must be in the top comment section of a page. If the #acl directive is put after any normal page text, it will not be processed.
In our example page, TrustedGroup can read and write the page, while everyone else is not allowed to do anything with the page. This is a common rule to define an internal page that only certain people can read.
By having an #acl directive, the Default Page ACLs are overridden. It is generally a good idea to include the Default Page ACLs after your custom ACL declaration unless you have a specific reason to do otherwise. For or example, it would look like this:
#acl TrustedGroup:read,write Default
This allows our page to be modified by the TrustedGroup then process the defaults.
Page ACL Inheritance
One common snag people run in to is that a subpage (like Products/Foo9000) does not inherit the permissions of its parent page. This means that if you have custom permissions for the Products page, you must also copy those permissions to the Products/Foo9000 page.