permission for our 3 sales people!!! Help!

[pius222]

Hi, I have a contact management database, I want to set permission where if "sales person-1" logged-in as "sales1" he can only view contacts and all invoice history created by himself which is "sales1", not contacts created by "sales2" or any other users.

In another word, if the entire database has 100 entries, and "sales person-1" created only 10 entries, he can only view his 10, not the other 90 entries.

This way, I'd like to have our 3 different sales people only look at their own customers, order history, and invoice amount. One would not see the other two's customers and how much they've sold.

Thanks

[Fenton]

The most iron-clad method is to create a separate password and "Group" (Account in v.7) for each salesperson. Then you always know who they are. You can use the "record-level access restriction" in the password privileges to make it impossible for them to see another's records. Even if they manage to get on the other's records, they'll only see <no access>.

This of course is not very attractive or friendly, so one has also to build in navigation, restricting the found set always to their own records. Once again, since you always know who they are, you can use Go To Related Record [show, "their group to their name relationship"].

Finds must be controlled, always adding the criteria "their name" to each. All and all it's some work, to make it both secure, and yet look good and seem friendly. People don't mind (or even notice) control if it's well done.

Create some passwords and groups. The Group can be their name or ID. It is accessible to you the developer, but not seen by others. The passwords can be anything, and can change. That's the advantage of a 2-tier system.

Then create a field Status(CurrentGroups) function, Unstored (important) and see what you get when you log in. Once you get their name you can use it in a relationship to their name in the records.*

In earlier versions the Group associated with the master password is in all groups (a multi-line result), so you have to parse it out to get their name. In v.7 it no longer is (better); and it's not called Groups, it's Accounts; which are different, but can be similarly used.

You could alternatively roll your own custom login routine with regular fields. But, if it can be bypassed anywhere, they'll see the others' records. The password record-level restriction cannot be easily bypassed. If they bypass your navigation controls the most they'll see will be <no access> in the fields.

*There is one sticky point when they open the file. They cannot use Go To Related Record [""] when the file opens on a record that does not belong to them, because they don't have access to it! Even though they only need access to read the unstored Status(CurrentGroups) calculation, which is the same on all records. Catch-22.

You can however go from another Login file, which does not have such restrictions. A good place for a pretty splash screen :-) That's one way to get started.

[Fenton]

Actually I don't think that Finds need to be controlled. I believe the <no access> records are automatically omitted. I did this quite a while ago. If so, less work for you :-)

[HampMac]

Hi, I'm sort of a newbie, but the way I'd handle this project is to create three different identical layouts that are locked down pretty tight. When salesperson-1 logs in, she is taken to layout-1. On layout-1 there is a portal to table-1 that uses salesperson's name as the relationship key. Make sure that only related records can be viewed. When salesperson-2 logs in he is taken to identical layout-2 that only allows him to create, view and modify records associated with him. And so forth.

As with everything Filemaker, there are probably a dozen different ways to accomplish what you are trying to accomplish with this project, but I hope my suggestion will at least get you started thinking the "Filemaker way". Also if someone knows a more efficient way to handle this project, please share your ideas.

HampMac

[Fenton]

I didn't really go much into the "control the interface from the login file," other than using it as a starting point. As HempMac says, you can use it as the interface, never allowing the salespeople into the main file, presenting all data in portals in the interface file.

You would have to find ways to enable everything they needed to do from the external file. In the case of salespeople this might be fine, as they don't do reports, etc..

You still need a way to know who is who. I maintain that the built-in FileMaker passwords and Groups (or Accounts) is the safest. And, with only 3 salespeople, not a big problem to set up, once you figure out how to parse their login from Status(CurrentGroups).

A custom login, using a FileMaker field, also works, but depends on your complete control of the interface. How about the Window menu? The main file is going to be visible there; you can just drop down to it, unless every action is trapped within a Loop (extra work), or you use a plug-in to remove it (extra money, but worth it if they'll pay :-).

[HampMac]

Fenton makes some good points. Using the built-in login would be the easiest and most secure way to go. The open script would be something like:

If ( Get ( AccountName ) = "Salesperson-1"

GoToLayout ( Salesperson-1 )

ElseIf ( Get ( AccountName ) = "Salesperson-2"

GoToLayout ( Salesperson-2 )

And so on. Then on each layout there is a portal to Table-1 that uses the Salesperson's name as the Relationship Key. Then individual salespeople would only be able to see their own records in that portal. You could then create additional locked find scripts to generate reports or lists that only show that individual's clients' information.