MindTouch Permissions Best Practices

Hierarchy

Before you start permissioning, you need to have a hierarchy to permission.  It's highly recommended that prior to diving into MindTouch and creating pages, try drawing out on a white board or on a piece of paper the main spaces that you want to create.  From there you can then create a skeleton for the departments to fill in.  Here is a sample hierarchy that we use within our company:

• MindTouch
  • Accounting
  • Development
  • Marketing and PR
  • Product Mgmt
  • Sales
  • Sandbox
  • Support

Creating Groups of Users

With the hierarchy segmented out, you know exactly the groups formation that you will be segmenting out within your company.  If you use AD, LDAP, or another external authentication system, then there is a good chance that this segmentation is already configured within the groups of the external auth.  To add groups to MindTouch, take a look at our Group Management section in our User Manual.  

Applying Groups to hierarchy

Now that you have your groups configured, we can apply permissions to the hierarchy.  To start we want to make sure anyone that can login to the wiki has access to the Top Level page, which in my Hierarchy is called MindTouch, otherwise when the user authenticates into MindTouch they will not be able to see any of the pages as they won't have permissions to the Parent of the hierarchy.  Recommended permission is Semi-Public and then add exceptions for the managers of MindTouch so they can change the content on the home page.

If we look at the hierarchy below, I've highlighted a breakdown of the permissions necessary:

• MindTouch (Permissions: Semi Public  Grant List: Editors of the Main Page Content)
  • Accounting (Permissions: Private  Grant List: Accounting Group)
  • Dev (Permissions: Private  Grant List: Dev Group)
  • Marketing and PR (Permissions: Private  Grant List: Marketing and PR Group)
  • Product Mgmt (Permissions: Private  Grant List: Product Management Group)
  • Sales (Permissions: Private  Grant List: Sales Group)
  • Sandbox (Permissions: Public   Grant List:  No restrictions)
  • Support (Permissions: Private  Grant List: Support Group)

 The private permissions will make it so only people in the Grant List can see and access the pages in that section.  For example, if a user in the Dev group logged in, they would only see the Dev tree and the Sandbox as that is Public, but they would not see any of the other pages unless they are also a part of those groups.  The reason I kept the Sandbox Public is so all users have an area to test out editing and functionality of the wiki.  

One final note, if the department top level page, i.e. Accounting, Dev, Sales, etc., has any subpages before applying permissions, make sure you check the checkbox at the bottom of the permission dialog that says "Apply these permission changes to all children pages" so that the already existing children pages inherit the permissions.  If there are no subpages under the parent department page, then any new pages that are created below the parent page will automatically inherit the parent pages' permissions.