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 <ccbible...@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
> 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.
> 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).
> 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]
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
** 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.