Session based DB

[rivet]

Has anyone work on a DB that is 'Session' based.

I have multiple users that need to keep their data separate and secure from other users. (e.g. with a Student DB, a teacher should only be able to view their students infomation)

What is the best way to approach this. I been thinking a session table, and accessing data via portals but they will loose the find feature of filemaker and I will have to create something for finds. The other option is to have them work directly in the table, with me locking down standard navigation and forcing the find script to add their account key to every find request.

hope that is clear, and if you have any suggestion I would love to hear them.

[Ender]

I think you've got the idea. Filtering records to show only those that the current account needs access to can be done through relationship filtering and Find filtering. Both are useful and can be implemented for different types of things within the solution. Bear in mind that record filtering can be fairly complex to implement across a solution.

Somewhere you need to define the access rules for which records users need access to. You probably have various types of Staff that need access to different things. For example, maybe Teachers need access to view thier own class, but not edit (or only edit some tables & fields), whereas Secretaries might need access to enter and edit key fields having to do with all Students and Enrollments.

For security purposes, access restrictions can be done by assigning each Staff account to their respective privilege sets, and defining those privilege sets to have read, write, or no access to records in each table. As far as limiting a particular privilege set to only thier own records, this gets a little trickier. Under the "Limited" option for Records access, you can define a calc that spells out the rules for what is accessible. It might look something like:

Session::gRoom# = Enrollment::Room# and

Enrollment::Status = "Active"

The trouble with using record level access privileges alone is the annoying messages that show for any records the user doesn't have access to. For this reason, the filtering of relationships and Finds is still a good idea.

Relationship filtering requires the filter to reside in the current layout's table (or one of the tables between the current table and the target related table). This might mean pulling the filter criteria from the Session table to the current one with an unstored calc. In this manner, the records in a portal could be filtered to only show those for the current teacher's Room# or whatever. But you'd also want to make sure the filtering allows for accounts with more access (and maybe no Room#) to see all the records. This can be done by using a multi-key on the child side of the relationship and having the unstored calc determine the correct parent key based on the privilege set or whatever.

For the Finds, filtering can simply be scripted while in Find Mode by using a Set Field [] to insert a value from the Session table into the Find criteria.

Keep in mind the Session table should only have globally stored fields. When a user logs in, you can populate a few useful fields in the Session table with things the user might need as they proceed through the solution. Alternatively, you could link a Staff file to the Session table, and only populate a global gStaffID in the Session table. Then access the user's information from that Staff TO.

Anyway, that's more info than I really meant to type, but this stuff gets complicated. Hopefully it makes some sense.

[rivet]

Wow, I knew I was getting into something bigger. I will start experimenting. Thanks for the tips

[bruceR]

As mentioned by Ender, you can do scripted finds. Since you are using FileMaker Advanced, that means you can redefine the Find command so that command-F always runs YOUR script instead of a basic FileMaker Find.

Since your script would always add teacher ID to the find action, that's all you'd need to do.

What Ender does not mention is that if accounts are set up properly, you don't even need to do this. A user NEVER sees other records even if they find "*".

Edited July 16, 2006 by Guest

[rivet]

I have been playing a custom find menu and working on the other navigation, such as 'Show Omitted Only. With this, I am trying to add the constrain find, but I might just remove the option all together.

My next big step /decision is, do I break this out into multiple files. Say there are many departments that need to work with the student data in unique ways. I could have a common log-in process, that directs the user to the proper file. I like this idea, knowing that everything to do with that department is contained in it's own file. It seems cleaner, but my 'data senses' are tingling. Fortunately I am off next week, so I will let is simmer.

Thanks for your replies.