Help with record level security? Thanks

[panache]

HI, folks. This is my first post, so bear with me if you will.

I work for a residential school. We've created several related databases, including "students.fp5," which contains all the info on our kids. In this database, there are (among others) two fields, "nameClass" and "nameHouse." One lists the class a student is in (eg. class one, class two, etc), the other lists the residence the kids lives in (eg. House A, House B, etc.). I want a teacher to be able to browse ONLY the records that contain his/her students. For example, if I teach in Class 2, I should only be able to browse the records of students who are in class 2.

I can't get this done for the life of me. I thought, "Well, I'll make a admin (super user) level password and a user level password, set the user as the default, and be done." Problem is, we have many users with varying levels of "accessability."

Administration should be able to edit and browse all records, create new records, delete records, etc. Office staff should be able to browse and edit but NOT delete. Direct care should be able to BROWSE ONLY. If I set a default password, which is it? The Administration? Office? Direct care?

Filemaker seems to only want to look at who created a record, and limit "browsability" based on that, but it won't do. I created a login field, and tried to limit records browsable to "loginField=nameHouse" or "loginField=nameClass" but it didn't work.

Thanks. This has been making me nuts for months.

[Razumovsky]

Hi Panache,

One solution might be to forget about Filemaker passwords beyond the admin/user levels, and design/script the per user access into the files. You would assign each teacher a unique password that they would enter into a global field when they opened the database. Each student record would have a hidden multi-key field that would hold the passwords for each teacher they had a class with (you would probably want to do this through a lookup/script, and have a seperate file that would store teacher names and their respective passwords). Teacher A would log on, type in their pass, and have the related student records appear in a portal based on relationship GlobalPass::PassMultiKey. You would have to make sure that all your find and navigation scripts incorporated this relational filter as well.

Just a thought.

-Raz

[HazMatt]

This depends on whether or not you want to specify a password for every individual user or if you just want to create a password for the group they are a part of.

You might be able to get away with 3 passwords:

developer - "Access the entire file" should be checked. This is your password.

admin - Deselect "Design Layouts" and "Edit Scripts"

office - Deselect "Design Layouts", "Edit Scripts" and "Delete records

[ssb]

I have implemented the record level access in FM Pro 6 using a simple calculation that compares the Status(CurrentGroups) to the Group Name field. The Group Name field is auto-entered to contain the value Status(CurrentGroups). Even with simple calculations though Left(Status(CurrentGroups),8)=Getfield("Group Name), record access from the server is very slow (30 sec for 180 records compared to 7 sec with no record level access limits). Filemaker tells me I need a faster computer, and admittedly I don't have a real server, just a new Athlon 2400 with 512 MB RAM and a trial version of FM Server 5.5. Does anyone have similar trouble?

Thanks,

SSB

[Anatoli]

What do you mean you don't have real server? You have the FM trial version.

FYI -- that will be slow in FM...