Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Ken Murphy
  Where is Ken Murphy?
 Springhill
 Canada
 Ken Murphy
 To: solomon sackey
  Where is solomon sackey?
 texas
 Texas - United States
 solomon sackey
 Tags
Subject: RE: menus for different user groups
Thread ID: 155112 Message ID: 155288 # Views: 2 # Ratings: 0
Version: Visual FoxPro 6 Category: Menus
Date: Saturday, December 29, 2007 6:11:29 AM         
   


> >
> > Solomon,
> >
> > Lets look at a practical example - an accounting application. In a traditional VFP app, you would have a main menu that might contain "GL/FR, Inventory, Payroll, Accounts Receivable, Accounts Payable, etc." Now, you don't want all of the users who have access to that accounting application to be able to go into the payroll portion of the app. You therefore must do something with your menu to prevent unauthorized users from accessing the payroll menu item. Boudewijn recommmends GenMenuX, and if you are creating a traditional application, that is probably the way to go. To use this (or any VFP menu) you will need to create a user table and a user rights table. These two tables will be the key to your application's security, so you will need to encrypt these tables. You will also need a method for maintaining the data in these tables, so you will need to create a data entry window or windows in which your user and permissions data can be entered. You will also need a password entry window at the beginning of the app that the user will use to enter his/her credentials.
> >
> > I do it a little differently. I create "Active Directory Aware" applications. In a Windows Server environment, your SysAdmin will use a utility called "Active Directory" to set permissions for files and folders and to create user accounts & user groups. Your SysAdmin does not want or need yet another user/permissions maintenance utility. I take advantage of this utility when I create my applications. I create a series of EXE files. In our accounting example, I would create a GLFR.EXE, a Payroll.EXE, an Inventory.EXE an AP.EXE, an AR.EXE, etc. To limit access to the Payroll.EXE file, the SysAdmin would begin by creating a "PayrollUsers" user group and he/she would add all of the payroll users to that group. SysAdmin would then grant Read/Execute rights to the PayrollUsers group and remove any rights for all other users. Now the only users who will even be able to see the Payroll.EXE file will be the payroll department users. If an employee transfers out of the payroll department, all your SysAdmin need do is remove that user from the PayrollUsers group.
> >
> > With this method, there is no need for you to create a Users and Permissions table or data entry utility, nor do you need a password entry window. You simply use the Windows LogIn credentials. In your payroll.EXE, you now need not ask the user for his password. You already know who the user is - you can use ID(), SYS(0) or GETENV([USERNAME]) to determine who the user is. You already know that this is an authorized user (he/she would not be able to see the Payroll.EXE file, let alone run it) so adding a password entry window serves no purpose. Best of all, with this method, you need not create, maintain or encrypt your user/permissions tables - indeed you do not even need user/permissions tables, nor do you need a data entry window to maintain this information - your SysAdmin will use Active Directory instead. As you can see - this is a lot less programming work. Not only is this a lot less work, it is the way that Windows applications are supposed to work in a Windows Server Environment.
> >
> > The key to this design however, is in properly defining your user roles. If you create the AP and AR functionality as a single EXE file, breaking it apart later will mean a total re-write, so do your homework up front. Take your time and define your application roles properly.
> >
> > Hope this helps.
> >
> > Ken
> > You shall know the truth - and the truth shall set you free. (John 8:33)
>
> Ken what if there is need for further differentiation within the payroll module, in that you further want to restrict access to some members of the say the payroll team to certain menu options?
>
> Thanks

I would do it the same way. For example, let's say that the Hourly Pay Rate for each pay grade can only be set by the Payroll Supervisor. I would create a PayGrade.EXE application that would be given to the Payroll Supervisor. In this case though your SysAdmin might not create a user group but instead, grant Read/Execute rights directly to that Payroll Supervisor user. Again, the key is in properly defining user roles. In this case, you would need to define a Payroll Supervisor role and along with it, define the tasks or roles that your payroll supervisor would perform.

Once you have these roles properly defined, you can then create as many different EXE files as you need. Your Payroll Supervisor might have access to all of the EXE files that belong to the Payroll Department, whereas a payroll data entry person might have access to only one or two of those EXE files.

By properly defining the tasks/roles, you can then leave it up to Management and the SysAdmin to define who has permission to do what. You might start out with only one user having access to your Employee Master Maintenance module (other users might be able to see some of the employee data, and might even be able to modify some of the data using other EXE files, but new employees would only be added by that user using the EmpMastMaint.EXE file.) Later on, as the company grows, that single user might grow into an entire department and so many users might need access to that EmpMastMaint.EXE file. You only need to worry about properly defiing the task of adding and modifying an employee record.

Hope this isn't confusing matters for you.

Ken
You shall know the truth - and the truth shall set you free. (John 8:33)

ENTIRE THREAD

menus for different user groups Posted by solomon sackey @ 12/25/2007 7:12:38 AM
RE: menus for different user groups Posted by Boudewijn Lutgerink @ 12/25/2007 9:40:40 AM
RE: menus for different user groups Posted by Ken Murphy @ 12/25/2007 12:34:17 PM
RE: menus for different user groups Posted by solomon sackey @ 12/29/2007 3:02:42 AM
RE: menus for different user groups Posted by Ken Murphy @ 12/29/2007 6:11:29 AM
RE: menus for different user groups Posted by solomon sackey @ 12/29/2007 8:50:35 AM
RE: menus for different user groups Posted by Ken Murphy @ 12/29/2007 1:42:48 PM
RE: menus for different user groups Posted by Benny Thomas @ 12/25/2007 9:41:40 PM