User Types And Permissions

This is an advanced topic as normally these will be set up for you.

Introduction

It is possible to create as many different user types as you need and set up permissions for them. In addition it is possible to set permissions for single users, and also set up permissions based on a combination of the user type and permissions specific to individual users. For example, if you have a number of people who are assigned to edit different sections and you don't want them to be able to edit other sections you can set up a user type of "section admininstrator" and assign permissions to each user who is assigned this user type differently - there do not have to be any common permissions at all.

By default, only superadministrators have access to set up other users and alter permissions, however these permissions can themselves be granted to other user types by that superadministrator.

Editing User Types

If you have permissions to edit the user types, the User Types menu option will appear under the User tab of the main admin menu.

This section is is essentially a list of the different user types and contains no other information, you can add to this list as you wish. Please note however that the basic types of "superadministrator" and "administrator" should NOT be edited here - you can set different permissions for them but the actual text should remain unchanged. Therefore all you should do here is add, edit and delete further types without touching the ones already set up. This is the easy bit, setting up permissions for these user types takes more work and that is covered in the next section.

Permissions

Editing permissions for existing users or user types, or adding/deleting permissions is all done from the permissions section. If you have the credentials to edit this section, you will find it works in exactly the same way as other sections, with a number of entries in the table, and add, edit and delete buttons.

It is also prudent to mention at this point - be careful when editing this section - back up your data first!

Permissions are applied to sections (database tables) by selecting that table and then setting up permissions on a per-table basis. Each record that you will add or edit contains the section (table) followed by four fields: Permission Type, Setting, Operator, Value.

The types of permissions you will be entering are things like:

Permissions work heirarchically through user types, and are based on white listing, starting with the following rules:

The fields in the permissions table

Examples

The following example shows how to set up a basic view permission on a section/table to allow it to be viewed by anyone through the front end (main web site):

The following example shows how to set up a permission on a section/table via user type:

The following example shows how to set up a permission on a section/table via user id (this is the id of the user in the users table):

You can now probably see how other field matches work - you can specify a field name in the 'setting' field, and '=' in the operator field and whatever it should be equal to in the value field. There is one further special function you can enter into the value field to denote the user who is currently logged in, and that is 'current_user()'. This way you can set a table up to be editable only in as far as records in that table are 'owned' by a particular user. One example of this is the user table itself, where if you are not an administrator, editing is only possible on the record of the user that is currently logged in. You can find this entry in the permissions table already, or here it is as example:

Note that together with an add permission of 1 with no setting or operator, it thus becomes possible for users to add themselves (ie register, sign up) and edit their own details but nobody elses, nor even see anybody elses data as you should not specify a view permission of 1 on the user table, but specify it in exactly the same way.

Hierarchy Of Permissions

Of course an administrator can see other users, and that is because a permission is set up for all actions on the user table by the sysUserType of administrator. It only takes one permission to evaluate correctly to give the permission - it works on whitelisting and one pass means that user is through. As a regular user will not have the administrator permission this match will never be made.