Wiki Permissions Survey

I wrote a couple of weeks ago about how wikis needs to be very careful about how much "workflow" overhead and limited access that they add to their applications, lest a growing community of shared information be killed by too much bureaucracy. I decided to do a survey of what permissions features the different wikis provide.

SocialText allows you to have multiple workspaces. You have create user accounts in each space for the users you want to grant access to. Workspaces, though they may be under one account, have no real connection to each other — they have different users, a different URL &c. There are also no user groups or permissions at all, as far as I could find. Any user is able to create/edit/delete any page in the space.

Confluence allows you to create different spaces and set permissions on each space. Permissions can be granted to individual users or to groups of users. Within a space, you can be granted access to 1) browse the space, 2) create and edit pages, 3) delete pages, 4) export pages, 5) create blog posts, 6) delete blog posts, 7) create comments, 8) delete contents, 9) create attachments, 10) delete attachments, 11) export the space, 12) administer the space, and 13) delete email. Each user or group can have a different set of these basic permissions. Additionally, an individual page can be “locked” so that only one person can edit it.

EditMe has permissions for page view, page edit, page creation, attachments and comments. There are no groups — so the only options for the permissions are “anyone,” “registered users” and “admin only.” Also, there appears to be no way to segregate content. To have different permissions for different pages, it looks as though you will need a second account.

Xwiki does allow you to have multiple workspaces within a single installation. There are Global Permissions, Workspace Permissions and Page Permissions. Users can have either View or Edit permissions at each of these levels. You must be an admin to delete items. Interestingly, it appears that you control permissions by adding markup into the page, rather than manipulating them through a dedicated permissions interface like Confluence. Personally, I found this somewhat confusing, but I admit I didn’t spend a lot of time with it.

JotSpot permissions work on a hierarchical model. You grant read/edit/create/email to individual users for individual pages and those permissions inherit. So if the admin prevents me from editing Page X, I also can’t edit any of Page X’s children.

There is only one workspace per account. But you could easily simulate multiple workspaces by creating top-level parent pages and setting permissions on them. This may be a clearer metaphor anyway, given the way permissions work in JotSpot.

There is also a great screen-cast tutorial on the JotSpot permissions system. Interestingly, there are features in the screencast that I can’t find in my beta site. For example, the screencast shows users groups and a user picker. I don’t see either of those features. So either it’s a new capability that hasn’t been made available to me yet, or it doesn’t work in FireFox. The entire editing interface already doesn’t work in Safari, which is frustrating enough, but if it turns out that FireFox doesn’t work properly either I’ll be most disappointed.

There seem to be two basic paradigms at work here. The majority of wiki providers have chosen to offer either per-page permissions (EditMe & JotSpot), or per-space permissions (Confluence & SocialText). XWiki offers both page-level and space-level permissions. [Confluence is presently working to add page-level permissions.] I don’t really see inherent advantages one way or the other. My guess is that as these products become more widely used the developers will have to build in multiple ways of managing access to accommodate different customers.