schemas - fundamental issue

[miasma]

Kind of a normal design problem I'm running into with my database...

For this project, I have a table of users who have access to the site. However, each user is broken down with an access level, a 'client','staff', or 'admin'...

Right now, I have one table with a field for that persons access level. However, things are slightly changing and there are some pieces of data that I might need for 'client's that I wouldn't have for staff or admin...

Should I be starting up a new table and separating out the different access levels? Is there a better to do this that I'm not thinking of? I'm pretty sure theres an accepted practice since this seems to be a pretty fundamental issue.

[kparker]

An approach that uses "access levels" is always going to run into problems as life goes on and things get complicated, because it imposes a single heirarchy on your access requirements. Look at what real operating systems do: you get to assign rights on a case-by-case basis. And almost always you get to also use that wonderful concept 'groups', so you can hand out permissions on a job-function-related basis and then assign individual users to groups, rather than having to make dozens of settings each time you add or remove a user, or move them to a different place in the org chart.

It's a lot more work up front, but the payoff is sane, secure, flexible administration.

[miasma]

I'm pretty sure that whats set up right now is similar to this groups idea... there are only going to be 3 groups, the client/staff/admin that I mentioned... and each user belongs to a particular group.

But say there's information that a client has that is not needed for the other groups.. or information for an administrator that is not needed for client or staff... should I be seperating out into different tables? a users_client table, users_staff, users_admin? It sounds like where I should be headed... only the headache comes when I want to add in newer 'groups'

[kparker]

there are only going to be 3 groups ... client/staff/admin
and each user belongs to a particular group

Nope, this sounds to me like it's just a way to use NAMES to accomplish the same limited, hard-coded heirarchy you would have with access levels as NUMBERS.

To have complete flexibility, you need to do this:

(1) Each user has a unique id.

(2) You can create arbitrary named groups.

(3) Each user can be a member of as many groups as is appropriate.

(4) Each item that requires access restrictions has an Access Control List: each row in the ACL references a single group (good) or user (not so good) and specifies what rights that group or user will have.

Now, you may not need all the flexibility such a scheme offers, but as soon a straight heirarchy of increasing access rights doesn't do what you need, then you do need this!

[kparker]

... it's not that hard to program all this, and you only need to do it once.

[Anon]

Well, the way I have mine set up... whcih is still in the works, is that I have a ACL database of sorts, which gives a numeric access level based on job function. I have a SECURITY.INC file that contians functions to check the security rights a person may have to a certain file. Than I use the functions in line in the PHP documents (HTML) to create dynamic content for each person. It works well so far.