Hiding buttons based on Login

[jnp102]

Hi everyone,

I'm in a bit of a bind and have read through many many threads looking for an answer. I see people talk about it but can not get it done for some reason. I have a database that users log into. This info is from a table where I have the username, password and access level. This then directs them to a form with several buttons on it (in an option group). I do not want some buttons showing on this form depending on the access level indicated in the table. Can some one help me with writing a bit of code to get this done.

Thanks
jnp102

 

[GymRatPA]

'Reset the Email notification/DELETE fuction visable FALSE when JOE/462 or BECKY/066
Me!btnEMail.Visible = True
Me!btnDelete.Visible = True

If ((GetUserID() = "KOP00462") Or (GetUserID() = "KOP00066")) Then '
Me!btnEMail.Visible = False
Me!btnDelete.Visible = False
End If

The default is to have them display for all but these two managers.

 

[jnp102]

That's great info! What if I would want it based off of the access level. So basically when they login it checks the login table and sees the access that they have and then limits the what they can see from there.


any help in the right direction would be great.

jnp102

 

[BobJacksonNCI]

jnp102,

One of the challenges is that identifying the user can vary. The following works for me using Windows 2000 with user identification based on their login entry.

I'm thinking it will work for you, too, but that's my disclaimer.

In general, this database has a primary startup form with buttons to select other forms. I use logic to make the buttons visible/invisible depending on access to be allowed.

Hope this provides some help,
Bob


I have a table, MgrTB_tlkpPrivileges, that contains selected users who are to have access to specific forms that others cannot. The structure is:
PrivID - Autonumber ID field
SignOn - User's Windows sign on entry
LastName - For User identification
FirstName - Ditto
AllowHR - True/False (yes/no,boolean) indicates whether User has HR access
AllowExitInterview - True/False indicates if User can look at exit interviews

Following are global variables. (They're not required, but might be useful for later development):

'FOLLOWING USED TO LIMIT ACCESS TO SELECTED OBJECTS
'THESE ARE SET WHEN frm_MAIN is loaded using the table tlkpPrivileges
Public pblnHR As Variant 'T/F-Allow use of HR forms.
Public pblnExitInterview As Variant 'T/F-Allow use of the Exit Interview form.

Following is code triggered by the On Load event for the main (startup) form:

TABLE VALUES ARE 0 (FALSE) OR 1 (TRUE). NO MATCH RETURNS NULL
pblnHR = DLookup("[AllowHR]", "MgrTB_tlkpPrivileges", "SignOn = '" & User & "'")
pblnExitInterview = DLookup("[AllowExitInterview]", "MgrTB_tlkpPrivileges", "SignOn = '" & User & "'")

'IF HR MENU ACCESS NOT ALLOWED, MAKE BUTTON INVISIBLE
If Nz(pblnHR) = 0 Then
Me.cmd_HR_Functions.Visible = False
Else
Me.cmd_HR_Functions.Visible = True
End If

'IF EXIT INTERVIEW ACCESS NOT ALLOWED, MAKE BUTTON INVISIBLE
If Nz(pblnExitInterview) = 0 Then
Me.[Exit Interview].Visible = False
Else
Me.[Exit Interview].Visible = True
End If

Separate module used to identify the User. We include this in all new databases. That's why the global variables are listed separately. (If that makes any sense at all.)

Option Compare Database
Option Explicit

'Declare APIs
Declare Function GetUserName Lib "advapi32.dll" Alias "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long
Declare Function GetComputerName Lib "kernel32.dll" Alias "GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) As Long

Public Function User() As String
'------------------------------------------------------------------------
' Determines current NT user using a SQL call
' 10/23/02
'
' Returns the current NT user name
'
' Usage:
' stUser = User
'------------------------------------------------------------------------
On Error GoTo Err_User

' Display the name of the user currently logged on.
Dim stUser As String
Dim intLength As Long
Dim intDummy As Long

stUser = Space(50)
intLength = 50
intDummy = GetUserName(stUser, intLength)
User = Left(stUser, intLength - 1)

'FOLLOWING ADDED TO IDENTIFY AND STORE THE CURRENT USER NAME
UserName = Left(stUser, InStr(stUser, Chr(0)) - 1)

Exit_User:
Exit Function

Err_User:
Select Case Err.Number
Case Else
End Select
Resume Exit_User

End Function

 

[GymRatPA]

Bob I could not have said it better.
We also use similar under Oracle OBDC. The Securty tables can be very complex, but must be thought out by a good planner. When done right, like yours, an application and restrict down to add/chg/del in any app or form.

 

[jnp102]

Bob,

Thanks for that info. It looks like it will work the way I need it to but there are two things that I am having a problem with. The first, is that I can not use the workstation ID method. I would love to, but can't. So I would imagine that I need the form to store the userid info somewhere so it can check the table with the appropriate info. The other, when I implement the code to see if something is visible or not, it's only checking to see if the word Admin or User is listed in the table and then granting access from there. I need it to look in the table for the UserId that was given, verify the password, look at the access level (there are at least 5 different levels) and limit access from there. Not sure if this is possible or not but any help would be appreciated.

 

[BobJacksonNCI]

jnp102,

Our setup is using Windows 2000 (NT) for security, meaning we work off the User's original login. Which means worries with passwords. If you're using Access security, you'll need to figure out how to look up that login information. Hopefully, someone will post with help on that as I cannot take the time to search for it myself.

However, "...verify the password..." sounds like you've developed your own security. You'll likely need to post more details of the process for assistance.

The above needs to be resolved first, then I'm confident the rest can be taken care of.

Bob

 

[BobJacksonNCI]

Which means worries with passwords."

should have read:

"Which means NO worries with passwords."

Sorry!
Bob