Created by: gwideman, Nov 14, 2011 1:37 am
Revised by: gwideman, Nov 20, 2011 9:23 pm (16 revisions)

In this article, I enumerate the roles and permissions for Wikispaces, given the "Projects" feature, as best I understand it. This is as of current writing, 2011-November.

Applies to

The availability of many of the permissions described here depends on:
  • Wikispaces subscription level
    • Below Super level, permissions may only be set in particular combinations of View/Edit/Comment/Create/Delete, such as site-wide consistent treatment of pages as "Private" or "Protected". At Super level, wikispaces offers "custom permissions" where these can be set separately, per page (and similarly for the defaults for wiki and project). That said, the custom permissions are still not as custom as might be hoped, as no special permissions are accorded for project membership -- more on this below.
    • No permissions that confer privacy of content are available for free subscriptions
  • "Education" classification
    • The "Projects" feature is only available on sites categorized as "for education". (Really, this is not support for Projects in the wider sense, it is narrow support for "Project Based Learning")

User Classes

User classification
Description
Anonymous
"Everyone" not logged in to the site
Wikispaces logged-in user
Member of Wikispaces, but not of this particular site
Wiki member
Member of this particular wiki site (mysite.wikispaces.com)
Organizer
Wiki member who has been given "organizer" status
Site Creator
The Wikispaces member who created the site. The Creator is initially also an Organizer, though can be demoted to Member. About the only special role of the Creator is that Creatorship of the site is permanently tied to the Creator's wikispaces account.


Member of Team P-T
Wiki member who has been made a member of team T within project P.
(Note: Though team members must be wiki members, they may or may not be organizers. However, since organizers can already do whatever a team member could be permitted to do, for organizers team membership is moot. So team membership only makes sense for ordinary wiki members.)
Member of Project P
Teams are nested within Projects, but memberships are granted at the Team level only. A member of team T within project P is thus a member of project P. (Currently, membership in a project confers no special permissions, in fact actually reduces possibilities. This is a significant flaw, in my view, as discussed below).

Permissions

Structure level
For Object
Permission action
Settings; grants action to selected role




A wikispaces site:
mysite.wikispaces.com
Site
Overall site admin, including
  • managing users
  • site theme
  • CSS etc
Organizers only

Default page perms
  • View
  • Edit
  • Create
  • Comment
  • Everyone
  • Wikispaces members
  • Wiki members
  • Organizers only

Individual site-level pages
  • View
  • Edit
  • Everyone
  • Wikispaces members
  • Wiki members
  • Organizers only

"
  • Edit (as controlled by Locked)
  • Organizers only (Locked)
  • No effect (Unlocked)

"
  • View (as controlled by Hidden)
  • Organizers only (Hidden)
  • No effect (Unhidden)

Files
  • upload
  • download
Follows site-level default Page View and Edit perms?




Project
Default page permissions for this project
  • View
  • Edit
  • Create
  • Comment
  • Everyone
  • Wikispaces members
  • Wiki members
  • Organizers only
  • Team members only
  • NOTE: No "Project members only option"




Team
Default page permissions for this team
  • View
  • Edit
  • Create
  • Comment
  • Everyone
  • Wikispaces members
  • Wiki members
  • Organizers only
  • Team members only
  • NOTE: No "Project members only option"

Individual team-created pages
  • View
  • Edit
  • Create
  • Comment
  • Everyone
  • Wikispaces members
  • Wiki members
  • Organizers only
  • Team members only
  • NOTE: No "Project members only option"

"
  • Edit (as controlled by Locked)
  • Organizers only (Locked)
  • No effect (Unlocked)

"
  • View (as controlled by Hidden)
  • Organizers only (Hidden)
  • No effect (Unhidden)

Files
  • upload
  • download
Follows team's default page permissions?




Note: Permissions grant various actions to various user roles. However, permissions may only be set by Organizers. This is not a bad constraint for the default permissions at site, project and team levels. However, it does constrain opportunities at the individual page level.

Working towards "Collaboration-oriented" roles and permissions

In this section, I examine how we might apply wikispaces' roles and permissions to achieve some or all the requirements for collaboration, as described in my other article here: Permissions use cases.
In particular, we want to know whether we can accomplish at least the following distinctions:

Actions on a document
User roles
Create
Delete
Edit
View
Comment
Doc creator
Y
Y
Y
Y
Y
Content contributor


Y1
Y1
Y1
Content consumer



Y2
Y2
Prospective consumer



Y3
Y3
Random public



Y4

The permissions marked Y1 through Y4 represent permissions that might be turned off when the document is in preparation, and then progressively turned on during later phases as it is published to a larger internal, then external, audience.
Furthermore, we'd like to be able to implement these permissions for two or more separate sets of content.

Initial constraints

The first thing to understand is how many groupings of content, and groupings of users, does wikispaces provide to us, onto which we would try to map the desired permissions.

Grouping of content

Content is only grouped in two ways, which are nested
  • Associated to this wiki
    • Associated to one or more project/team-thingies.
      • This is complicated by the fact that a user can be a member of only one team under each project. So though project-team seems to be a two-level structure, really it has no more power than a single level.

Group/Roles of users

Wikispaces offers four site-role levels:
  • Everyone
  • Wikispaces members
  • Wiki members
  • Organizers only
However:
  • "Everyone" + "Wikispaces members"= Public For most purposes, we don't care whether a user who lacks a membership to our site also lacks a membership in Wikispaces. (maybe it matters for comments and spam).
  • The "Organizer" role can't really be used as "most permissive content access level: The Organizer is only available as "the most permissive content role" on sites where it is OK for content contributors to also have full admin control over all aspects of the site. This is where there is only one, or a very few, content contribs who trust each others' motives and competence. However, in most cases the "most permissive content role" cannot be Organizer.
Next, although a user's team membership is independent of whether that user's wiki membership level is "member" or "organizer", since "organizer" is not usable for content access control, we are really just left with membership in each team as nested within wiki membership. (No permissions are affected by Project membership per se, only team membership).
So, for controlling access to content, we are left with the following group/role distinctions. User is:
  • Public
    • Associated to this wiki
      • Associated to zero, one or more teams
Previewing what is to come, this leaves us with only three levels to which to map distinct levels of access for contributor/consumer/everyone else, along with distinctions between different sets of content. There are only two levels, if content is not to be publicly accessible. This will prove to be inadequate.

Permission scenarios narrowed down

The following section presents several site usage scenarios, and how wikispaces permissions might be used to support them.

Broadcast model

This is basically the wikispaces "Protected" site setting, available at the Plus subscription level, with commenting optionally allowed for general public.


Actions on a document
User roles
Wikispaces role
Create
Delete
Edit
View
Comment
Doc creator,
Content contributor
Member
Y
Y
Y
Y
Y
Content consumer,
Prospective consumer,
Random public
Public


Y
Y
[Y]
Any member is permitted to edit any document. Not suited to protecting numerous authors from each others' deliberate or accidental edits. At any rate, not suited to private collaboration.
At the Super subscription level, custom permissions can be used to make individual documents private to the site. However, they are still visible and editable by all members.

Private site, without teams.

This is basically the wikispaces "Private" site setting, available at the Plus subscription level,


Actions on a document
User roles
Wikispaces role
Create
Delete
Edit
View
Comment
Doc creator,
Content contributor,
Content consumer,
Prospective consumer
Member
Y
Y
Y
Y
Y
Random public (no access)






This does allow members to collaborate in private, but there are no guards on who is allowed to edit or see what. All members can see or edit anything.
The custom permissions available with the Super subscription don't improve that situation. However, the custom perms would permit selectively making some documents available to the public. (Really, this is just the flipside of using custom perms on the Protected site to make some docs private.)

Private site, with teams to constrain editing and viewing

In this scenario, team (or project) permissions are set to "Protected to wiki", which restricts editing to team members only, and allows viewing by wiki members, but not public. This is configurable with the Plus-level subscription (and assumes site is categorized for Education to enable the project features.)
There can be multiple projects, so multiple groups of members editing their own docs, but not each others'.
Note: It would be useful to avoid setting up more than one team per project, as users can only be a member of one team per project.


Actions on a document
User roles
Wikispaces role
Create
Delete
Edit
View
Comment
Doc creator,
Content contributor
Members of
particular team
Y
Y
Y
Y
Y
Content consumer (trusted)
Member of wiki



Y
(selected content
w/cust perms)
Y
Content consumer
(untrusted or prospective),
Random public
Public



(selected content
w/cust perms)
Maybe
As the table notes, with the custom permissions of the Super subscription, it is possible to set the view audience for selected pages to team, wiki or public.
Document exposure can be controlled as follows:
  • With the default for the project/team set to "Protected to wiki", set specific-page perms for selected documents to "private to team".
  • Conversely, with the project/team set to "Private to team", set specific-page perms for selected documents to "protected to wiki".
  • In either case, custom perms can also be used to make selected documents public to the world.

Comments on use cases:
  • Publishing to selected audiences: The flexibility in permissions described here is a start toward supporting selected audiences. But note that custom permissions may only be set by Organizers, not by page authors or team members themselves. Consequently, this important control over document exposure is not available to the team to manage autonomously.
  • Privacy during draft stage: The ability to set individual docs to private-to-team supports a degree of privacy during draft stage, though not as great as if viewing could be further limited to the creator.
  • Favor most-private default perms? In order for content contributors to be able to create documents that start and remain private, the default project/team settings should be "Private to team".
Other wrinkles
  • As I currently understand it, with a Plus subscription, documents created by a team can't be made public to the world, as the settings to do that are not include in the standard permission options. Instead these appear to require custom permissions. [email enquiry on this point is pending].

What use cases can't be served:

The central problem of the above configuration is this:
  • The "content consumer" role is implemented by the "protected to wiki" permission on pages
  • Content consumers are enrolled as wiki members
  • Therefore, content consumers can view content-consumer-level pages from all teams.
There is no way for teams to each define their own content-consumer audiences. This is fatal if our wiki is a vehicle for collaborating with two different other outside groups (say clients), and each of those groups should not see the info shared with the other.
The various alternatives which get closer to that goal are seriously flawed:
  • Have multi wikis with only one project/team per wiki
    • expensive, and requires redundant maintenance of multiple wikis. Or...
  • Make content private to team, and enroll consumers of that content as team members. This does keep the content of each team confined to their own audiences. But
    • the team exposes all its content to content consumers, no selectivity.
    • it allows content consumers to edit that content as well, asking for deliberate or accidental edit trouble.
    • So this idea is generally not useful.
  • Content consumers = team members = view only; Content contrib = Organizer = editing. But this has numerous problems too:
    • Since Organizers are users who can view and edit anything in any team and control site admin, it gives content contributors too much authority to create accidental or deliberate trouble. So this is only usable for scenarios with a single content contributor, or a very small group of admin-savvy content contribs.
    • the team exposes all its content to content consumers, no selectivity.
    • Again, generally not a practical scenario.

Bottom line

The goals stated at the beginning of this section (Working towards "Collaboration-oriented" roles and permissions) to support basic collaboration can't be accomplished with the current permissions features of wikispaces, even with Projects/Teams and Custom Permissions enabled.