Permissions, Roles, Users, Groups and Workflow
In a Space, there is a "placeful workflow policy" applied, which controls who gets to access what, based on the state of an object, and the users/groups assigned in the Sharing tab. There is a currently a single, hard-coded Space content workflow which does not complicate matters with approval/reviewer. There is an in-development reviewer/approval workflow, this can be applied once ready, by configuring the workflow policy.
Item workflow states
In the default content workflow, the following workflows are available:
Private: This is the initial state of an item inside a Space, the idea being that the owner of the item just created it, and can work privately on it, without showing it to others.
Private to project-members: The owner of an item can make the item "Private to project-members", so that all members of the space can see and edit it. Note that when an item is Private to project-members, it cannot be seen/accessed by Space viewers. More on this below.
Published: When an item is ready to be displayed to Space Viewers, it can be "Published" by any space member and it will then become visible to Space viewers. Note that item is still editable by Space members, even when it is published.
There are 3 kinds of Roles that can be used in a Space. These are:
Space Manager ("The Editor"): A Space Manager can edit the space itself (title, description, rename, etc.). He can also control who gets to do what actions using the sharing tab. Space Managers are assigned on a Space by turning on the "Can Edit" checkbox against their name.
Space Member ("The Contributor"): A Space Member can edit all content that he has access to inside a Space, as long as it is not in the Private state. Space Members are assigned on a Space by turning on the "Can Add" checkbox against their name.
Space Viewer ("The Reader"): A Space Viewer can only view content that is in the "Published" state, in that Space.
Illustration 1: Typical Space Permissions
In a typical space we have the above sharing tab depicting the permissions applied. In this screenshot depiction:
- Logged-in users do not have access to the space. This is the default and should be retained empty like this, unless you want to allow all logged-in users access to a Space.
- customers1, customers2 and customers3 are users who have only got Space Viewer role because they only have their "Can View" checkboxes checked. Thus the 3 customers users can only view published items on the Fantabulosa Island space.
- Management is a group of 10 users. The entire group has been granted the Space Member role by checking the "Can add" checkbox. This means that all 10 users (and any future ones, as well) will be able to participate as full members of the Space - and edit any item that they can access.
- siteadmin and siteadmin2 have been given the Space Manager role, by turning on the "Can edit" checkbox. This allows them to edit the space and further add / remove more users from permissions.
- Inherit permissions is turned off by default: This prevents any permissions applied above/outside the Space from interfering with the Space. If you turn this on, then all the permissions applied above will also become applicable in this Space. It is usually very highly recommended to leave this off, as is.
Caveats & Notes
- Both groups and users can be added to any Role. If a group is added, then all members of the group get the same access as specified.
- Spaces can be nested within each other. Even in the nested case, as long as the Inherit permissions checkbox is left off, then the Space behaves like a unique "silo" of permissions.
- Owners of container type of items get special permissions on all items contained in the container. So for example if a member called management1 created a folder in a space, and made it private to team. After this, the management2 user came and added a gallery, and further added pictures inside this gallery, but left all of this to private to owner state. The management1 user will in this case, also be owner on the private items and as such retain full access to all items contained in the folder created by him. This is by design, and is correct behavior.