Permissions

From Habari Project

Jump to: navigation, search


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.

Contents

Permission Types

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.

binary 
the permission can be set to allow or deny.
CRUD 
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.

Binary Permissions

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.

Super User

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.

CRUD Permissions

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.

Groups

As mentioned above, permissions can be assigned to groups. The things a user can and cannot do are determined by their group membership.

Default Groups

When Habari is first installed, three groups are automatically created, admin, anonymous, authenticated.

Admin

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.

Anonymous

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.

Authenticated

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.

Combining Permissions

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.

Further Details

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.

Personal tools