Thanks. I have reversed the order as of now.
1. Reports Only 2. Data Entry Only (NO Master Entry) 3. Manager (Data Entry + Master Entry) 4. Admin (All Forms & create users)
On Tue, May 15, 2018 at 10:45 PM, Charlie-gm ccbibleman@gmail.com wrote:
I'll apologize in advance some of this is somewhat basic, but I want to be clear about my approach.
One thing that I do in VFP is to first subclass all the base classes into it's own .vcx. So I get something like "mybutton" which was subclassed from button.
Now, in pretty much all those classes, I add a property "naccess". I default the value to 1 (which can, of course, be overridden when I instantiate it on a form).
In addition to that property I add another "lRemovebyAccess". I usually default this to .F.
I also have a global object that has a property "userlevel" - when the application starts, that property gets set to some value (numeric) based on whatever rules are used for that application.
Then, in the .Init() method of all my baseclasses I have the following code snippet: IF THIS.lRemovebyAccess == .T. AND THIS.nAccess > oApp.nUserLevel THIS.Visible = .F. THIS.Enabled = .F. ENDIF
So now, whenever I put the buttons, grids, spinners, images, whatever... on a form, I can set the .lRemovebyAccess and nAccess of the objects.
One thing to remember is if you put code in .Init's of your instantiated buttons (the ones you drop on a real form), you need to call DoDefault() in that code (of course).
The lRemovebyAccess is a little redundant, but it gives a very quick way to make everything visible if you're having problem debugging (e.g. .SetAll()). Also, it made it easy to completely swap the "security importance" of the app with just 1 baseclass property setting: that is, change the concept from specifically picking things to hide to specifically picking things to show.
I would recommend at least 10 levels of access: I've rarely seen more than 5, but you just know...
Also, I ran into a case where not only did they want tiered access levels, they also wanted to let one Admin see and do somethings and another Admin to see/do different things. I won't clutter up this already long email with that stuff but it essentially was just another property ".cfuncaccess" that could contain a string of characters. And then in the logon the user was assigned his "string" (usually a single character). From there the above IF statement was modified to include the check of strings, etc.
I've put this in my generic visual class library that I use on all projects. A couple times about halfway into developing they said, '... oh yeah, we want to also add security levels....' My prime contractor freaked out, told them it would add like a year to the project, yada yada. But after one meeting to be clear on requirements, I rolled it out in a week (which actually upset my prime contractor because they wanted to charge a lot more money... heh).
-HTH -Charlie
On 5/14/2018 1:29 AM, Ajoy Khaund wrote:
Hi All,
In my applications I have added a user table where there will be field to define the user level.
Level - 1 Admin: can add users and has access to all Level - 2 Manager - cannot add user but has access to all others Level - 3 Operator - can add transactions but cannot create masters (eg. add/edit a customer)
[excessive quoting removed by server]