Coding for different user access levels

darbid · Jun 29, 2010

I am pretty sure that what access offers is not what I am looking for but I am happy for you guys to tell me I am wrong.

I want to code for different users. Not only for forms/tables etc but also the controls they see on a form and for example when a person clicks on something my code does different things based on the type of user they are.

My users structure at the moment is not complicated but I would like to learn how to do this the "right way" and I hope make it future proof.

I hate passwords and do not want to build passworded levels. Either the person has the right to see or do something or they do not.

I have a users table which contains there names, ID, contact details. The easiest but I suppose the wrong way of doing this would be to add a column for each user type. eg Admin - Special User type 1 - etc - Normal User. This would mean that with a new user right I would have to change coding and tables.

The other idea I had was to have only one field and use some kind of numbering system. 1 being Admin - 1000 being normal user. Then I could add user types between these numbers. This might get complicated with coding later.

So how should I be doing this.

gemma-the-husky · Jun 29, 2010

first you need a way of determining who is logged on

either by access security, by a designed log in method, or by reading the windows login name

then for each form/process you need code that tersts the user, and makes certains controls visible/not visible, and certain procedures avaialble/not available. THs bit is not easy, and may take a lot of programming - and you need a way of doing that doesnt involve a load more programming each time you add a new user.

so maybe store a usergroup, and assign the user to a usergroup on login/startup, and then code your special stuff for usergroups, rather than individuals

darbid · Jun 29, 2010

gemma-the-husky said:
first you need a way of determining who is logged on

either by access security, by a designed log in method, or by reading the windows login name

Ok - I have got this. The first time the user starts their local-front end they have to choose their given name from a list. I know their windows login name so I check their given name against that on the computer they are on, thus they cannot choose someone elses name (unless they are logged in as someone else). This is saved in an .ini file locally.

gemma-the-husky said:
then for each form/process you need code that tersts the user, and makes certains controls visible/not visible, and certain procedures avaialble/not available. THs bit is not easy, and may take a lot of programming - and you need a way of doing that doesnt involve a load more programming each time you add a new user.

Yep understood. Until now I have only done checking code where not everyone can see the control or not everyone can do something.

gemma-the-husky said:
so maybe store a usergroup, and assign the user to a usergroup on login/startup, and then code your special stuff for usergroups, rather than individuals

could you expand on this. Would this be a table that can be joined to my table of users?

Poppa Smurf · Jun 29, 2010

Quote:
Originally Posted by gemma-the-husky
so maybe store a usergroup, and assign the user to a usergroup on login/startup, and then code your special stuff for usergroups, rather than individuals

could you expand on this. Would this be a table that can be joined to my table of users?

This means that you will need to add a field in your users table called usergroup or accesslevel. Then code your forms for each user group or access level. So after an user logs in you will know his user group, then using your code the relevant fields on the form will be displayed.

In my databases after I determine the user's access level I store this on a hidden form and close the login screen. I refer to this access level so that the user can access the relevant forms and reports etc. This method eliminates the need to keep the login screen open so that the access level can be determined each time a form or report needs to be opened.

darbid · Jun 29, 2010

Hello Poppa (love the name)

Poppa Smurf said:
This means that you will need to add a field in your users table called usergroup or accesslevel. Then code your forms for each user group or access level. So after an user logs in you will know his user group, then using your code the relevant fields on the form will be displayed.

So a little example

Admin = 1
Boss = 5
Secretary = 10
User = 20

Then simply for a Admin/Boss form

if user = 1 or 5 then
show form (or do whatever)
end if

For Secretary only

if user = 10 then
show form (or do whatever)
end if

Thus I would have to always recode my IF clauses to add new groups at a later stage.

Poppa Smurf · Jun 29, 2010

Hello Darbid

Re the name when my sons were playing soccer many many years ago I was called Murph short for Murphy. At the time there was a cartoon called the Smurfs so I was called Poppa Smurf my wife was called Momma Smurf and the boys were called the Smurfettes based on the children in this cartoon.

Now to your question

So a little example

Admin = 1
Boss = 5
Secretary = 10
User = 20

Then simply for a Admin/Boss form

if user = 1 or 5 then
show form (or do whatever)
end if

For Secretary only

if user = 10 then
show form (or do whatever)
end if

Thus I would have to always recode my IF clauses to add new groups at a later stage

Suppose you have a form that will be used by ALL users regardless of their user level. This form will have all the fields required for all levels of access. These fields visible property will be set to Yes.

Now on the Load Event or Open event which occurs just before the form is displayed you would have the following

In this example field_name1,field_name2 etc are the names of the fields that you do not want to be displayed for the relevant access level

Using the CASE statement eliminates the need to use multiple IF statements which at times can be confusing and cause some trouble.

Private Sub Form_Load()
Select case User
Case 1,5
' 1 - Admin level
' 2 - Boss
field_name1.visible=false
field_name2.visible=false

Case 10
' 10 - Secretary
field_name11.visible=false
field_name12.visible=false

Case 20
' 20 - User
field_name8.visible=false
field_name9.visible=false
End Select

End Sub

To add a new user level, say 25, that will have the same displayed fields as the Secretary, all you need to do is add the level to the line Case 10. This now becomes Case 10,25

Now if the new level 25 has different fields then you add the following in the above code.
Case 25
' 25 - Cleaner
field_name18.visible=false
field_name19.visible=false

darbid · Jun 29, 2010

Got it. Great. Thank you.

It is getting late in the land down under.

I am an Aussie in Germany. I was less than impressed with our boys performance in the World Cup against Germany. I really copped it at work the next day.

Thank god we have a good swim team, hockey team and usually tennis players.

gemma-the-husky · Jun 29, 2010

i think the smurf has put you on the right track

just to confirm - the reason you want to manage the access levels by group rather than by individual is because then your programme doesnt need changing for new users - you just need a table in which you can assign a new users access group level.

darbid · Jun 30, 2010

Thanks Dave as well.

There is one thing that is niggling me.

Up until now I had "2 groups" "Boss View" and "Users"

I designed a form for these 2. The boss saw and could do more.

Then the boss said I want "U1", "U4", "U30", "U6" to also see the boss view on this form. (U = User)

Thus I could not elevate them to Boss View, but they were no longer part of the "User Group". It is kinda like I need to have 2 Groups. Groups based on users and Groups Based on Views.

I realise that I cannot code for every eventuality up front but I am wondering that if you guys were faced with this probability (and I can imagine it happening in the future as well) what would you guys do?

HiTechCoach · Jun 30, 2010

darbid said:
I realise that I cannot code for every eventuality up front ...

Actually you can.

darbid said:
... but I am wondering that if you guys were faced with this probability (and I can imagine it happening in the future as well) what would you guys do?

There is actually a product that you can "plug in" that does this. I have used it before on projects and it works quite well See: EZ Security Manager

You can set permissions down to the controls on objects by user group.

At least it might give you some ideas.

Poppa Smurf · Jun 30, 2010

Do "U1", "U4", "U30", "U6" work in the same section? You may find that work areas will be your groups

Before get into the level coding develop a matrix on a spreadsheet with a list of the menu items that will be available to all levels.Then in your columns across the spreadsheet place your users U1...U30... etc.

This will highlight any problems or possible grouping of users to make your coding easier.

I have attached an example, I use this method for a staff of 600 but it is based on their staffing level e.g. staff, team leaders, supervisors, managers etc.

darbid · Jun 30, 2010

HiTechCoach said:
There is actually a product that you can "plug in" that does this. I have used it before on projects and it works quite well See: EZ Security Manager

Thank you, I will have a look at it.

Poppa Smurf said:
I have attached an example, I use this method for a staff of 600 but it is based on their staffing level e.g. staff, team leaders, supervisors, managers etc.

The matrix looks great and got me thinking.

I could create the user groups as we did above. This will mean one column in the users table.

Then where I have to implement my group level security I will name each one. I will then add a second column to the user table with a comma seperated list of these names. If the user has this name in his user record than he can see it.

eg. Imagine I have a group of controls to edit employee details. I would name this "EmpDet"

So User groups 1,5, 20 can see it.

Then 2 people that do not belong to these 1,5, 20 have to edit employee details as well. In a my 2nd column I would add "EmpDet".

Code:

If InStr(specialfield, "EmpDet") > 0
    
    Show controls

Else

    Select case User
    
    Case 1,5
        
        Show Controls
    
    Case 20
        
        Show Controls
    
    Case Else
        
        Do Not Show Controls
    
    End Select

End If

This means that to add or remove these special users that do not belong to a group AND I have named the view then I simply add this name to the special field.

Coding for different user access levels

darbid

Registered User.

gemma-the-husky

Super Moderator

darbid

Registered User.

Poppa Smurf

Registered User.

darbid

Registered User.

Poppa Smurf

Registered User.

darbid

Registered User.

gemma-the-husky

Super Moderator

darbid

Registered User.

HiTechCoach

Well-known member

Poppa Smurf

Registered User.

Attachments

darbid

Registered User.

Similar threads

Users who are viewing this thread