One of the things that is hard to do when designing a piece of software is predict the interactions which its features imply. A case in point is the access control list (ACL) capability that will in Habari's next release.
The purpose of ACL is to control what people are able to do and what posts they are able to see.
Owen Winkler has given an outline of how Habari's ACL system works in Habari Permissions System Overview.
As is described there, post permissions are based on the CRUD model. Can a user create, read, update (edit) or delete a post? To these are added the deny permission, which denies access to a post whatever the other permissions on it.
All users who are not logged in to Habari belong to the anonymous group. This group is only able to read and comment on posts, whether entries or static pages. If a plugin adds a new content type to Habari, the plugin generally gives the anonymous group read access to the new content type.
Things become more interesting and complicated when considering users who are able to log in to Habari.
All logged in users are automatically added to the authenticated group. Out of the box, this group has the same access rights that the anonymous group has.They can read and comment on all post content types.
Habari comes with four post-related tokens out of the box.
- Permissions to one's own posts - which controls permissions to the posts which one creates.
- Permissions to all posts - which controls permissions to all posts of whatever content type.
- Permissions to posts of type 'entry' - which controls permissions to all posts with the content type entry.
- Permissions to post of type 'page' - which controls permissions to all static pages.
One important characteristic of Habari's ACL system that may not be obvious is that permissions on a given post are additive. Logged in users can belong to different groups, each of which has different permissions on a given post. In deciding whether a user has access to a given post, the permissions from each group to which they belong are combined in such a way that they have the highest access level to the post from each group to which they belong.
Take the example of a user who belongs to a group called authors. This group is able to do anything with their own posts of whatever content type, and their own posts only. They also belong to a group called page editors. This group can read or edit any static page. They cannot, however, create or delete static pages. They cannot even read other content types. Remember, out of the box this user also belongs to the authenticated group, which can read all posts of whatever type.
Combining these permissions shows that, when logged in, the user will be able to create, edit, read, and delete their own posts (given by membership in the authors group), read and edit all pages by all users (given by membership in the page editors group), and read all posts of whatever type by all users (given by membership in the authenticated group).
When creating groups and adding users to them, administrators need to take the interaction between the tokens allowed to each group into account.