How to structure multiple users with multiple permission levels?

Question

The site I am working with has a somewhat convoluted way with dealing with users and permissions.

These are the user types:

• User
• Facility Approver
• Facility Admin
• Corporate Approver
• Corporate Admin

Now there are also facilities, and that is where these permission levels come into play. Facilities are linked to users and user levels in a table like such:

user_id     facility_id     userlevel
joebob      ABCInc          Facility Admin

Pretty simple so far, but now what I want is be able to allow one user level to set restrictions on another user level for a certain facility. For example, I'm the Facility Admin and I want to only allow Users to submit certain forms. How would I store this?

I was thinking a new table that links facility_id, userlevel and permissionlevel. But what exactly would permissionlevel be? An int? Or would I add columns to the table like canOrderThings or canSearchForStuff?

I was seeing if like this would work, but it seems like it would get a tad messy and hard to keep track if you have a large number of permissions. How would you add permission levels without throwing everything out of wack? Or even setting permission levels would be a bit challenging I think.

Also user levels are directly linked to users in the User Table, but those server different purposes.

Is there a completely better way to structure all of this?

Answer 1

Using a second table for options is a good idea. Some forum frameworks use this method.
Each of your users are given a UserGroupId which is usually an Int since they are easiest to work with. UserGroupId of 1 for instance, could be an admin, 2 could be a teacher (depends on your organization).

Then you have a table called Permissions, on this table you include all options as Columns, something like this.

UserGroupID --|-- SearchEnabled --|-- CanOrder
             1                   0           1
             2                   1           1

Using a simple binary system, 1 enabled, 0 disabled, you can control options for each user group. This allows you to get all permissions with a single query, while still offering a very large area for customization.

You don't have to use binary numbers though. For instance you could use values 1,2,3 where 1 is full permission, 2 is partial, and 3 is zero. It depends on how specific your regulations need to be.

Now before you allow a user to perform an option you do a simple check on the users permissions (which you should store in an array or a class for quick access). For a function that enables search you would use a condition such as

If ($user['SearchEnabled')
{
   $generate->SearchOptions();
}
else 
{
   $generate->Error('NoSearchPermissions');
}

Using binary numbers has the obvious benefit of simply check if TRUE or FALSE. If you use a different numbering system it would require a bit more work, checking the specific value
If ($user['SearchEnabled'] == 2 || $user['SearchEnabled'] == 1)

Answer 2

Well, if I wanted to implement permissions in my application, I can do this 3 ways (I can think of on the top of my head):

1. On the users table (and record if you are using a orm) put a level int. So for example a level 1 user can only view forms, level 2 can post, level 3 is admin and can edit, etc. Then in the views you just check to see what level the user is and echo the form is they can edit etc. (Based on your question I assume this is what you are already doing)

   Pros:

   • Easy to set up
   • Lets you group permissions together.

   Cons:

   • If you need a level between 1 and 2 you have to do a lot of work. So, it's harder to add levels in between afterward.

2. Join a permissions table with the users table. Basically what the other answerer described in this thread.

   Pros:

   • You aren't confined to levels, you can add as many levels in between as you would like.
   • You can fine tune what you want each user to be able to do.

   Cons:

   • You can't group permissions, but I suppose you could just assign them all at once if you wanted.
   • It's more work to tell a user what s/he is because you can only list all the permissions or make a massive switch to determine if they are an admin or not. (Ex: am I a regular user? well I can edit forms, but not search?)

3. Combine these, so basically on the user table you could have a string that had values like "admin", and on each page just look if they are an admin or not.

   Pros:

   • You can add as many times as you want without throwing anything out of wak. Types like "super admin" or "somewhat less admin"

   Cons:

   • If you are fine-tuning every user, you would end up with a lot of new user types fast.
   • Adding new user type strings may be difficult, unless user type string table was joined tabled to permissions, but now we are getting pretty complicated.