If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

Login system hirearchy

Hello all,

I have this concept question. I was looking at some login scripts/process/etc and I want to create a hirearcy login. Meaning ceritan users can have access to certian parts of the website.

So now instead of having in the DB a 1 being active user and 0 being requring activation. Could I instead use letters? I dont see why not. lets say A=not active B=Active but limited visiblity, C=Admin controls, active and moderation, and so on. Or do I need to create some function to return the values I desire?

If anyone can confirm or explain this that would be great. Thanks!

For want of a nail...the horseshoe was lost. For want of a horseshoe, the steed was lost. For want of a steed...the message was not delivered. For want of an undelivered message.....the war was lost.

As long as you set the format of the corresponding table column to enum, char or varchar then there is no reason why not at all. Or you could add another column to store the of access and just keep your active user column as it is.

I would keep the active/inactive status separate from access level, as they are two different concepts. So active can be Boolean (0 or 1), while access level can be pretty much whatever makes sense for your application.

Actually, I disagree with nogdog. At least my personal implementation of user levels has been 0 = inactive 1-9 = user levels as defined by the app

So, let's say you create a new account, and set its status to 0 initially pending confirmation. Now when whatever process is followed in order to activate the account, how do you know what access value to set it to now? If it will be "obvious" for whatever reason (e.g. a small number of users and all the changes are being done manually), then fine, I suppose, but it still feels to me like two different things: you can be an active admin user or an inactive admin user; or you can be an active regular user or inactive regular user; etc. While the system can grow to have n number of user types, the active/inactive status will likely remain a simple either/or choice. If you want it to be completely automated while only using one field, you'd probably need two separate values for each user type, e.g. 0 = regular/inactive, 1 = regular/active, 2 = moderator/inactive, 3 = moderator/active, 4 = admin/inactive, 5 = admin/active, etc....

(Actually, last time I did something like this, "activation" was not Boolean, but was a timestamp; so Null for that field indicated inactive while a non-null timestamp indicated active while also providing a bit of tracking info of a sort.)

So, let's say you create a new account, and set its status to 0 initially pending confirmation. Now when whatever process is followed in order to activate the account, how do you know what access value to set it to now? If it will be "obvious" for whatever reason (e.g. a small number of users and all the changes are being done manually), then fine, I suppose, but it still feels to me like two different things: you can be an active admin user or an inactive admin user; or you can be an active regular user or inactive regular user; etc. While the system can grow to have n number of user types, the active/inactive status will likely remain a simple either/or choice. If you want it to be completely automated while only using one field, you'd probably need two separate values for each user type, e.g. 0 = regular/inactive, 1 = regular/active, 2 = moderator/inactive, 3 = moderator/active, 4 = admin/inactive, 5 = admin/active, etc....

(Actually, last time I did something like this, "activation" was not Boolean, but was a timestamp; so Null for that field indicated inactive while a non-null timestamp indicated active while also providing a bit of tracking info of a sort.)

Whoops this would be a problem of me misreading the OP's post. I have a separate column for confirmed, such that you can't log in if you aren't active AND confirmed. 0 (or inactive in the ui) is a status for people being removed from the system, or blocked from using the system for one reason or another. As far as "if you want to make them active again, what do you do?" The answer to that is simply a rollback to their previous UserLevel as I have an audit table tracking most changes in the database.