Wiki permissions structure

Overview

This article provides some background regarding Zoho WIki's permissions features, and how these are applied to the fablabsd wiki.

In broad strokes, the wiki-subwiki structure look like this:

... with the Action Group pattern repeated for each Fab Lab SD action group. (* subwiki corresponds to Zoho wiki's 'workspace' feature.)

The permissions we want to implement look like:

... where 'Edit' stands for various operations to do with creating and maintaining content.

Basically, we want to enable Action Groups to create and manage their content, some of which they will share with the community ('Public') and some will be for internal purposes to support their activities ('Private').

As in many systems, sets of related permissions are grouped as 'roles'. It is a role, rather than individual permissions, that is accorded to users.

Although roles could be accorded to individual users directly, it is easier to to manage users in (zoho) groups, and accord roles to the zoho groups. That way as members adopt different stations in action groups, they can get the related permissions by being added or removed from different zoho groups.

The rest of this article documents the details for this scheme.

Zoho Wiki permissions system

Zoho documentation references:

• User Administration
• Wiki Permissions
• Support forum: Permissions versus roles docs?
  

Roles

For our purposes, the permission system distinguishes the following Roles:

• Owner of the wiki
  
• Administrator
• "Ordinary Member" - logged-in user
  • Individual member, or a Group of members
    
• Public (visitor who is not logged in)

Wiki permissions per role, and their options

These are the permissions accorded to the wiki Roles, as defined by zoho.

Notes:

• * Can be set yes or no by admin or owner
• [1] Page permissions can be set at Wiki, Workspace or Page level. If not set at a level, the settings from the level above take effect.

• [2] As 0f 2015-10-24, not implemented, but will be added as part of create/delete permission. (See bug: Rename page and URL not available to full-permissions user.)

• [3] As 0f 2015-10-24, not implemented. GW may lobby for this. But it overlaps with not wanting users to disrupt the site map inadvertently.
  

 Fab Lab SD's choices

Here are settings which allow us to implement public and private wiki workspaces per action group:

• Action Group members will be accorded the role of "Member"
• Everyone else (Fab Lab users not in that action group, and public) will be Public visitors.

(Notes as for previous table.)

Zoho Users, Groups system

Users are known to zoho by their user id, which is the email address they used to register (and which can be later changed).

A user can be accorded one of the roles (discussed in the previous section) directly. However, this becomes difficult to manage beyond a few users, and requires member managers (Action Group stewards) to have Admin permissions.

Instead,

• Wiki Owner or Admins can set up zoho Groups,
  
• give the Groups the necessary workspace permissions,
  
• grant the Action Group stewards just the capability to add and remove members from those groups (using the Group 'moderator' permission).

I (Graham) had hoped that we might further refine the management of users by using Zoho's Shared Contacts feature, so that their membership info comes from a single source (so far as Zoho is concerned).  However, it turns out that, as of 2015-10, Shared Contacts cannot be used in the Groups > Invite (add users) dialog. See forum post Groups invite feature can't see shared contact list?

Details

[TODO Diagram]

[TODO Discussion]