From Habari Project
Habari's permissions system gives site administrators finegrained control over what users can do. Users are assigned to one or more groups, and groups are assigned one or more permissions, through the group's page in the admin. Permissions are never assigned to individual users.
There are two types of permissions in Habari, binary and CRUD. binary permissions generally apply to administrative tasks. CRUD permissions generally apply to post content types.
- the permission can be set to allow or deny.
- the permission can either have a combination of create, read, edit, and delete, or be set to deny. deny overrides all other permissions on the content type on which it is set.
A binary permission can be set to either allow or deny and action. You can either do the action involved, or you cannot.
Default Binary Permissions Tokens
- Manage comments on all posts
- Controls whether the group can moderate and edit all comments on the site.
- Manage comments on one's own posts
- Controls whether the group can moderate and edit comments on their own posts.
- Manage tags
- Controls whether the group can delete, rename, or merge tags.
- Manage options
- Controls whether the group can change basic site options.
- Change theme
- Controls whether the group can change the site's theme.
- Configure the active theme
- Controls whether the group can configure the site's active theme.
- Activate/deactivate plugins
- Controls whether the group can activate or deactivate plugins.
- Configure active plugins
- Controls whether the group can configure the active plugins.
- Use the importer
- Controls whether the group can import content from other sources into the site.
- Add, remove, and edit users
- Controls whether the group can add, remove or edit users, and reassign their posts to other users.
- Edit own profile
- Controls whether the group can change their own user data.
- Manage groups and permissions
- Controls whether the group can add, delete, or edit groups, their members, and their permissions.
- Manage logs
- Controls whether the group can view the site logs, and delete log entries.
- Make comments on any post
- Controls whether the group can comment on posts, no matter who created the post or what it's content type is.
The Super User permission is a special binary permission that, if set to allow, overrides all other permissions and allows the user to do anything. The admin group, by default, has the Super User permission set to allow.
Permissions on Posts
One of the most common access you might want to control is they types of things users can do with a post.
These are the default post-related permissions:
- Permissions on one's own posts
- Controls what users in this group can do with posts of any content type that they created.
- Permissions to all posts
- Controls what users in this group can do with any posts of any content type, whether they created them or not.
- Permissions to posts of type "entry"
- Controls what users in this group can do with posts of type entry, whether they created them or not.
- Permissions to posts of type "page"
- Controls what users in this group can do with posts of type page, whether they created them or not.
As mentioned above, permissions can be assigned to groups. The things a user can and cannot do are determined by their group membership.
When Habari is first installed, three groups are automatically created, admin, anonymous, authenticated.
The admin group represents users who have administrative rights within habari. By default, members of the admin group have the Super User permission and can do anything on the site.
The user specified at installation is automatically added to the admin group.
The anonymous group represents users who are not logged in to Habari.
By default, members of the anonymous group are able to read published entries and pages, and comment on posts.
The authenticated group represents users who have been registered with the site. As new users are created, they are automatically added to the authenticated group.
By default, members of the authenticated group are able to read entries and pages, and comment on posts.
If multiple tokens apply to a single object (for example, an entry that you write would have at least three applicable tokens: Permissions to all posts, Permissions on one's own posts, and Permissions to posts of type "entry") then the most permissive setting is used. A granted permission in any of those tokens grants the permission.
Important: The exception to this is if a token is denied. Any denied permission overrides all other grants.
For example, if you have permission to read, edit, delete, and create your own posts, but the deny permission is set on the Permissions to posts of type "entry", you will not be able to access posts of type "Entry", no matter who created them originally. This behavior is useful, if, for example, you create a group entry_authors, whom you want to be able to create and edit their own entries, but whom you do not want to be able to access pages, or edit or delete entries written by other authors. Give the group create, edit, and read permissions on Permissions on one's own posts, and set the deny permission on Posts of type "entry". Note that in this example the entry_authors group will not be able to delete their own posts because the delete permission has not been set on Permissions on one's own posts.
If you're developing a plugin and need to manipulate permissions, you can read about how to do that on the Dev:ACL page. Details about the implementation of the permissions system can be found on the Core:ACL Class page.