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)
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/9c3fd043-71af-7c5e-cb92-8070e1f38...@gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
