Limiting user access to others files..

[bmusee]

I have 4 salesmen that enter customer info into the database. I want to restrict each salesman to be able to work with his or her own info and not mess with the others.. Passwords for each don't work as they are able to edit the other salesmen... have I made myself understood and is there an answer..?

[QuinTech]

Hi bmusee, welcome to FM Forums!

If you create a field called "Salesperson", enter the appropriate data for each record, and then restrict a given password to a particular set, namely, "Salesperson=UserName", this should do the trick.

It sounds like you have maybe already tried this and it didn't work. If that's so, what exactly didn't work about it?

Jerry

[bmusee]

what I did was create a database called xxxx.fp5 for client contact info...I set up each salesman with his own password..but they all have the same "browse, create, edit records" privileges--I want to restrict each salesman to only be able to edit his own records..

[Steve T.]

Howdy, bmusee!

Yeah, individual record access is not as straight forward as one would hope, at least in FMP4-5... I'm not sure about 6. I think FMP added it due to user demand and called it RECORD LEVEL ACCESS or something but I don't know much about it but that's probably what Jerry is referring to...

Hi, Jerry! How do you "restrict a given password to a particular set" of records? In Access Privileges in FMP4/5, there is only layout and field restriction options. Does 6 have another option where you can apply the "Salesperson = UserName" rule/condition?

Thanx!

--ST

[QuinTech]

You're exactly right, Steve. Sorry for glossing over that.

In FM6, go to File>Access Privileges>Passwords. Select the password that corresponds to salesperson 1. Next to "Browse Records" change "All" to Limited..." In the calc box that comes up, enter:

Salesperson = "User1"

where Salesperson is the name of the field i described in my first post and User1 is whatever you entered into this field for the salesperson's name.

Do the same for Edit Records and Delete Records if you wish.

There are other, more robust, ways of doing this, but this is a good quick method.

J

[Fenton]

The other "more robust" way of doing security in version 5.5-6 is to create a separate Group for each person, and tie a single password to the group. You have access to groups via a calculation function, Status(CurrentGroups); set to "Do not store."

There is one glitch, which is that the master password's group always appears in Status(CurrentGroups). So you have to use a Substitute function to remove it (and its carriage return). But then you're left with a pretty secure way to know who is logged in at any time, which the users cannot tamper with (they can change User Name, which is available in the Preferences, Application).

If you limit record-level access for editing of those passwords so that the parsed calculation result of Status(CurrentGroups) = Salesperson, then they can only edit their own.

In version 7 you can do much the same, but it's much easier, because each person can have an Account, which you get with Get (AccountName); and it's only that one account.

Plus you can script the creation and deletion of accounts, and change the password; very handy for more than a few people.

[bmusee]

Thanks to You All