Menu
Community /Pin to ProfileBookmark
@NogDogNov 19.2012 — #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. @NogDogNov 20.2012 — #
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.)
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!
Sign in
to post a comment6 Comments(s) ↴
0
@NogDogNov 19.2012 — #0
@NogDogNov 20.2012 — #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[/QUOTE]
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.)