Link to home
Start Free TrialLog in
Avatar of brasiman
brasiman

asked on

How to inactivate a tab on a form based on permissions?

Hello! I have an access database (2010) and am trying to find the right code that will disable a form tab based on the permissions entered.

I created two tables:
1. Employees. Columns = Username, Password, FirstName, LastName, Level
2. SecurityLevel. Column = Level

For the Employees table, under the column "Level", i did a lookup to the SecurityLevel table and the "Level" column...this way its a dropdown. The two rows in the "Level" column are "Admin" and "Basic". So, when i setup a new employee in the Employees table, the Level column has a dropdown coming from the SecurityLevel column. The two options are "Admin" and "Basic". I hope that makes sense. :-|

Then, i created a form that requires you to enter a username and password to get into the form. The code for the username and password just say to look at the Employee table. If the username and password are correct, open a form. Very simple.

This form is a Navigation Form. On this Navigation Form I have two tabs. One tab is called Main. The other tab is called Admin. On the Admin tab, i set the Navigation Target Name to be the Employee table. This way, when my employees enter their password, there is a Main tab with a few buttons to open additional forms/tables. Then the Admin tab allows us to create new users. However, I don't want everyone to have access to my Admin tab. I am trying to find a way to disable the Admin tab for all users that do not have the Admin security level. So, when the log in, based on their username, password and security level in the Employee table, if their "Level" is Admin, the Admin tab is enabled. If their Level is Basic, the Admin tab is disabled. I have played with various code and can't tie the Employees table username, password and level together. Any ideas? Does this make sense? I hope it does. Thanks!!!
Avatar of Nick67
Nick67
Flag of Canada image

I'll put in a comment just to let you know I have seen your Q
Navigation Form
Those are funky MS created monsters, so what you have embraced for security gets much more complicated to do because the events and happenings of a Navigation Form are driven by a lot of custom-created MS code.

Now regular old Tab controls, those are really easy to sort
I have a Tab Control with five pages.
On each page is a subform control.
The TabControl is named TabMain.
Pages (the formal name for a Tab) are indexed from 0 (so I have 0 to 4 on the go)
Hiding the fifth tab?
Me.TabMain.Pages.Item(4).Visible = False
Very simple once you get the hang of the TabControl.

But Navigation Forms are a completely different monster from versions which end users run (Access 2013) but I don't develop in (I dev in A2003)  So I can't help you out with a Navigation Form.

Nick67
I'm going agree with Nick on this one.  It is extremely unlikely that you will be able to do what you want on this type of form since you don't have any control over the tabs.  If your security data is in a subform, you might be able to do something silly such as creating an opaque box that covers the secure data part of the subform and use the form's current event to check authorization.  Then show or hide the data by moving the box to front or to back.  I don't know if this will cause a flash or if you will be able to see the data for a split second before it is hidden.  

I would probably make the secure stuff a popup form so you have to click a button rather than a tab.  That will give you the ability to allow viewing/updating or not without resorting to tricks to get past interface weaknesses.
Avatar of brasiman
brasiman

ASKER

Is there a way to display the username that each user uses on the login form to log into the database? Then have code look to that username used and refer to the Employee table for the username and the Level column to determine if the Admin tab should be visible or not? I was thinking something like this:

If Security = 1 Then   (Security = 1 is referring to the SecurityLevel table, row 1, which is Admin)
Me.AdminTab.Enabled = True

Else

Me.AdminTab.Enabled = False

I just don't know what the code would be to look at what username was used to log into the database.
Rather than closing the login form when you open the menu, just hide it.  That way you can refer to the login form whenever you need to know who is logged in.
How do I do that?
ASKER CERTIFIED SOLUTION
Avatar of Nick67
Nick67
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@PatHartman
With ReturnUserName, I get the Windows username -- and can therefore dispense with passwords and just run with what Windows has.  That doesn't play if everyone logs on with the same name, or leaves their machines unlocked -- but the higher level folks run under their own IDs, so it works swimmingly.  Those low-level multi-user names aren't in the case select so they get minimal permissions.  Saves me from having to manage passwords or secure them.
There is little point to security if the app doesn't require a log in.  Once you have made the basics of a security app, you just import a few forms and tables into new applications so it is very little work and I never manage the logins.  That task goes to a user appointed admin.
I think you  missed my point.
Windows requires a login.
At that point I can base the security off of the Windows login /  Active Directory.
No extra usernames or passwords to remember/change/forget/share.

I use the username/computername, but the same facility exists to get ALL Active Directory data, in which case you can base the security off any type of AD grouping/membership that meets operational needs, and manage it through AD.

Which can be quite nice.
I didn't miss your point.  Very few organizations allow developers to control Active Directory and especially in large shops, they absolutely do not want to be bothered by having to manage application security for every single application that comes down the pike.

Just because a user has access to an application doesn't mean he has access to all functionality within that application.  Once you go beyond "all functionality", you need application controlled security.  And some applications even require data level security.  For example in an HR application, a manager can see the salaries, etc for his department  but he can't see information for all departments.  While you may elect to not force a user to specifically log in since you can obtain log in credentials by using API calls or other means, you still could still need internal application security and that means tables, forms, reports, queries.  However, for an application that requires extra security such as an HR app, you are going to be required to log in and since a lot of my apps contain sensitive information, I take the extra step to require a log in.