Upon Successful Login Change AFRs Form Version

[billgyrotech1]

Hi,



I have the database to open to a Login form. A user will select their name from the combo box and enter their password. When successful the Switchboard form opens.

example: wpeterson password: 581

My question is there a way to have the button "Open AFR" to select the proper form version (AFRs1, AFRs2, AFRs3, AFRs4) based on that user's security level?

Note: These forms have different levels of protection is why I chose this method.

wpeterson has security level 1 (administrator) shown in the SecurityLevels and the Employees tables.

Do the tables SecurityLevels and Employees need to be related?

I really appreciate any help,
Bill

[orange]

These forms have different levels of protection is why I chose this method.

How exactly have you tied Security Levels to Forms?

In general you would have Roles with Privileges/Rights.
For example, Admin role can see all Forms and full privileges
Clerk role is limited to Specific forms.

Then you assign user to a Role, and once assigned their privileges/rights are defined.

[billgyrotech1]

I appreciate the help orange. I was able to set up the Login by your suggestion on the Steve Bishop video.

Can you please take a look at the database? I hope it isn't too much trouble for you.

[orange]

Please address the question I asked after a quick look at your database. I couldn't see where you used security level with forms.

How exactly have you tied Security Levels to Forms?

[billgyrotech1]

I don't know how to tie these together after watching the videos. I like the idea of his one way to have a drop down combo box to select the user but not sure how to add the security levels.

Do the Security Levels 1-4 match the IDs in some way?

[billgyrotech1]

This way of security login seems very difficult to do.

Wouldn't it be better to have different versions for each user on their desktop computers?

[orange]

Bill,
You know your business and requirements better than anyone here on the forum (or anywhere else for that matter). You indicated in a post that your current database has been operational for 5 years. So you must have a (to do list) list of things that need to be modified, added, removed etc from operational experience or changes in requirements. Very few applications run for 5 years without modification.

Think of it this way - and it may be complex - if your boss said let's hire a database analyst/developer to build this. Someone has to provide a list of requirements, description of processes etc and some idea of priority, costs and time frame for the boss to make a decision to go/no go.

Do you or management have a clear set of requirements that could be handed over to a hired gun or for you and/or a project management team? It seems from your posts that this is now a priority.

Has anyone mapped out a description of the business processes in a document(s) or a diagram?

Steve Bishop's approach to managing different user/usertypes was to associate a role to the various forms in the application that that role could see. His approach assigns a user/person to a role. And by doing so, he restricted/managed the users to certain forms. His approach requires that forms and the behind the scenes routines are designed to deal with specific business processes. This approach can be referred to a Role Based Access Control (RBAC).

I'm not suggesting it's easy or simple. I'm just pointing out the underlying approach to what you are dealing with and some of the things to be considered.

In the Steve Bishop example, he relates user login credentials to user type; he also has a table the associates user Types and FormNames showing which user type has access. He has a global function to return the HasAccess (True/False) value when requested at Form load and Button click events; and he suggests making some controls not visible if that user type does not have HasAccess = True.

Good luck with your project.

[billgyrotech1]

I received a very well and thought out message from Mr. Orange and would like to continue my quest here if I am allowed of course.

Basically what I want to do is allow users in a certain group be directed to the correct version of the AFRs form.

But how? I thought a login screen was one way to do this. After watching some of Steve Bishop's videos I can understand some of the concepts but haven't been able to put it all together to have a solution to my thread.

Thanks again for any help or suggestions

[orange]

Bill,
Why would you mark this thread as Solved?
Is there anything in my post #7 that suggested

not being able to apply to my database properly

?
You indicated you didn't understand his Security Levels and how he dealt with Forms; I just tried a different description of what Steve's video was showing.
He even offers an option to download his code for users to see how he has done things.

[billgyrotech1]

I just thought of a different concept that might make better sense:

I set the database to open to Switchboard.

When a user clicks on the 'Open AFRs' button it pops up the Login form asking for the UserName and Password. Success will open the proper AFRs form from there.

[June7]

I use code during login to open MainMenu form bound to Users table and filtered by login info. MainMenu never closes so user info is always available for reference in code behind other forms to manage user activity. Usually to hide certain buttons.

Alternatives are to set global variables or TempVars which can be referenced from any procedure. TempVars can also be referenced in macros.

[billgyrotech1]

Thanks to June7 I have an updated Login form that has the UserLevel field that could serve as criteria for what version of the AFRs forms to be selected when clicking on the 'Open Form' on the Switchboard.

Is this possible now?

Thank you

[June7]

Only if Login form never closes.

I have never used the Switchboard builder wizard. I don't like it. I think the Switchboard is confusing and difficult to modify. There is a reason MS deprecated the wizard.

As is, Login form does not open when db opens nor do any buttons on Switchboard open Login. A login validation should occur before even going to Switchboard.

[billgyrotech1]

I can set it in the file options for the current database to open the Login form on database open.

[June7]

As I said, a form must remain open that has the user info if you want this available to multiple other forms/reports/procedures. Or use global variable or TempVars.

If only Switchboard form requires the info, it can be passed from Login to Switchboard other ways.

1. OpenArgs pass info and Switchboard then sets its own textboxes

2. Login form sets value of textboxes on Switchboard

3. Switchboard is a normal form bound to employee info as described in my earlier post