My part was keeping customer data that was AR separate from AP and vice versa. Credit limit was a field you needed to be ranked to change as well as writing customer notes or viewing customer notes.

On Mon, May 14, 2018 at 9:17 AM, Ajoy Khaund akhaund@gmail.com wrote:

Thanks trying that way. In my case, as I of now, I don't have to remove the middle part of a form.

On Mon, May 14, 2018 at 7:38 PM, Stephen Russell srussell705@gmail.com wrote:

...

Welcome to the Data Driven Life. It gets very complicated quickly, or

so I

...

fell into that hole when I tried this the first time.

I fond that you need to define rules in data that are set for each form. You hide what they shouldn't see with respect to buttons. Moving form content around is where I spent way too much time. If user access says that they have no right to the middle 1/3 of the screen I tried to shift the screen contents and I was never happy with my attempt at this. Currently, I cheat in HTML output when I do not render those parts.

On Mon, May 14, 2018 at 12:29 AM, Ajoy Khaund akhaund@gmail.com 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)

Now in the master entry forms in the Add & Edit button I can put some

code

...

to prevent Level 3 users from adding or editing.

I want Level - 3 users to be able to view the masters. So for them

add &

...

...

edit button will be disabled or some code will b there to tell them they have no access.

Is there a better way? Any ideas which u are implementing are welcome.

-- Regards,

Ajoy Khaund Neamati Road Bhogdoi Mukh Jorhat 785001 Assam, India

Tel: 91-376-2351288 Cell: 91-94350-92287 Mail: akhaund@hotmail.com Mail: akhaund@gmail.com http://teaanalyst.blogspot.com/

"Walking on water and developing software from a specification are easy

if

...

both are frozen."

• Edward V. Berard, "Life-Cycle Approaches"

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]

Thanks doing something similar. Ok I was thinking of a table with the list of forms also but now my mind is free.

On Mon, May 14, 2018 at 8:01 PM, Paul H. Tarver paul@tpcqpc.com wrote:

If I had to guess, I'd say that there are thousands of different ways to handle this. In the past, I've used several different methods depending on my needs at the time. The simplest method of controlling access is to check whether someone has enough security to see a screen or not before you run the form such as:

if vartype(glAdmin) = 'U' glAdmin = .t. endif

if glAdmin do form sys_system with .t. else thisform.utilities.msgbox('You do not have Administrator Rights to this screen!','FATALERROR') endif

• glAdmin is a global flag set when the user logs in to determine their

access rights.

However, because you mentioned a security level system, I remembered having a similar setup with one of my clients. Each user has a security level set between 0 and 10 where 0 is a very basic user with access to only a few things and 10 is Admin level which has access to everything.

We have a table that stores a list of all forms and the minimum security level necessary to even open the form and if the user meets the minimum security level the form opens.

In the INIT of forms, we call a method to enable or disable fields or buttons depending upon the specifics that take place within the form.

If I had it to do over again, I'd probably try to ditch the table with the list of forms as I believe I could accomplish the same thing using the Load method to check the user security before the form init. I have done something similar in the past using code similar to what I show above.

I'd be interested in hearing from others in how they would handle that.

Paul H. Tarver

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ajoy Khaund Sent: Monday, May 14, 2018 12:29 AM To: profoxtech@leafe.com Subject: Application User Level Access

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)

Now in the master entry forms in the Add & Edit button I can put some code to prevent Level 3 users from adding or editing.

I want Level - 3 users to be able to view the masters. So for them add & edit button will be disabled or some code will b there to tell them they have no access.

Is there a better way? Any ideas which u are implementing are welcome.

-- Regards,

Ajoy Khaund Neamati Road Bhogdoi Mukh Jorhat 785001 Assam, India

Tel: 91-376-2351288 Cell: 91-94350-92287 Mail: akhaund@hotmail.com Mail: akhaund@gmail.com http://teaanalyst.blogspot.com/

"Walking on water and developing software from a specification are easy if both are frozen."

• Edward V. Berard, "Life-Cycle Approaches"

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]

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]

With access rights it may be easier to assume everyone has access to everything and then only store what they don't have access to.