restricted access

[T Howard]

I have a database that tracks purchase orders, budgets,etc. I am wanting to restrict access to certain records. If a user is a division director, I want them to be able to see all purchase orders created by anyone in their department. If a user is not a division director, then they only see records they have created. I set this script up to run upon the file being opened. The globals referenced are calculated unstored fields. I am not sure whether to have them as global auto-entered calc fields or as global text fields and have the information set by the script. The script is set to run with full access privileges. I have not been able to make it work. Any suggestions would be greatfully appreciated.

Set Field [ purchase requests::gAccountName; Get(AccountName) ]

Set Field [ purchase requests::gDivisionName; authorized users::User_Division ]

Set Field [ purchase requests::gPrivilegeSet; Get(PrivilegeSetName) ]

Go to Layout [ “PR Input Layout” (purchase requests) ]

Enter Find Mode [ ]

If [ purchase requests::gPrivilegeSet = "Division Directors" or "Empl w Division Director Auth" ]

Insert Calculated Result [ purchase requests::Division; purchase requests::gDivisionName ]

[ Select ]

Perform Find [ ]

Else If [ purchase requests::gPrivilegeSet = "Users" ]

Insert Calculated Result [ purchase requests::Created By; Get(AccountName) ]

[ Select ]

Perform Find [ ]

End If

[Steven H. Blackwell]

I have not been able to make it work.

For a couple of reasons immediately evident:

1. The script is set to run with full access privileges. That means the Privilege Set is the Ful Access one as well.

2. This entire syntax is problemmatic.

Set Field [ purchase requests::gAccountName; Get(AccountName) ]

Set Field [ purchase requests::gDivisionName; authorized users::User_Division ]

Set Field [ purchase requests::gPrivilegeSet; Get(PrivilegeSetName) ]

Go to Layout [ “PR Input Layout” (purchase requests) ]

Enter Find Mode [ ]

If [ purchase requests::gPrivilegeSet = "Division Directors" or "Empl w Division Director Auth" ]

Insert Calculated Result [ purchase requests::Division; purchase requests::gDivisionName ]

[ Select ]

Perform Find [ ]

Else If [ purchase requests::gPrivilegeSet = "Users" ]

Insert Calculated Result [ purchase requests::Created By; Get(AccountName) ]

[ Select ]

Perform Find [ ]

End If

I'd recommend investigating Record Level Access and not using globals for this cosntruct.

Steven

[T Howard]

I have heard setting record level access before but I am still unclear how this works. I know how to restrict access to certain fields with the view, modifiable and no access but how do you restrict access based upon a certain criteria.

[Steven H. Blackwell]

It's done in the Define Accounts & Privileges Area under the Data privileges. Select custom and then you'll see the options.

Steven

[T Howard]

Thank you for the excellent advice. I did not explore the custom settings under view, create, etc. I had only looked at options under the field access. I tried your suggestion and it works but it brings up another question. How do I eliminate the records that show from the found set on opening of the file.

[Steven H. Blackwell]

How do I eliminate the records that show from the found set on opening of the file.

Do a find on something known to be in all records. The resulting found set will not include those records to wich the user has no access.

Steven

[Learner1]

Hi,

In the firm I work in, we are consdering using filemaker to create a small database to help us in the decision makeing process. One of my questions concerns security: is it possible to restrict the access to certain files to only the person which is concerned with it. For example, I want the HR manager to access only the files for HR.

Thanks in advance :P

Edited June 29, 2007 by Guest

[Ender]

Yes it's possible, but that may not be the best way to go. If you have the accounts set up in all the files, you can still enforce limited access for those accounts that don't need to do much in a particular file, but you gain the advantages of being able to pull bits of data into other parts of the solution, and your users aren't faced with login dialogs that they can't get through.

For example, everyone could log in to the same central file, and depending on their privilege set, get different choices of where to go in the solution. The HR staff may get choices for finding, viewing, or reporting on Staff, while the Lawyers get options to go into their Contact Manager or Time Log modules.

If you're building from scratch, you should try to put it all into one file anyway, for simplicity.

[Learner1]

Thank you for your help Ender but I'm not sure i get what you've said. Let's say that we are developping a system for time sheets. I want only managers from accounting for example to access the timesheets of employees in the accounting department.In other words people will have te get access to only the recrds they are concerned with in the same database.

[Ender]

That sounds like another reason not to isolate the HR module. If there's access to the Employee records (limited access), you can then (based on the Account Name), refer to the Employee record and know what department someone is in, or who they supervise or whatever. Then you can use relationships to timesheets records for the department or timesheets for people that are supervised by the current user.

The actual implementation will take some figuring out, depending on how you want it to work.

[Learner1]

Thanks Ender I'll try consdering your suggestions :P