limited record access by calc.

[raingirl]

If I am trying to restrict record access by calculation, I assumed that the users would only see the found set of records I restrict them to. Instead, they can only see information for the records I choose but see No Access on all the rest of the records. This makes for an ugly interface.

I tried creating a filtered TO and evaluating the calc from that TO but it keeps crashing the database.

What am I doing wrong?

[Fenton]

I don't know what you're doing wrong enough to crash the database. I don't know exactly what you mean by "evaluating the calculation from that TO." If you mean defining the field to evaluate by that TO (what you said), I don't think that's necessary.

Here's how I do it.

A calculation field, "_cAccountName," unstored, result text, = Get ( AccountName ). Evaluates on main table occurrence, where the data is (not anything special).

A text field, "Staff," (or whatever you call it), which usually auto-enters Account Name on creation.

A TO with relationship _cAccountName = Staff

Record Access limited by calculation, Get (AccountName) = Staff

I use the TO relationship instead of Show All Records (for affected Privilege Sets, may not be everybody). During regular Finds, and other operations, FileMaker is smart enough to filter the results to exclude the <no access> records. But not for Show All Records.

There is a "Catch 22," which is that FileMaker cannot evaluate _cAccountName on a record where the user doesn't have access. So, you can't let them just land on any record of that table when they first arrive.

You can have a similar TO, from another "navigation" table, on a Get (AccountName) calculation field to this table. The navigation table should NOT have this record-level access. That way you can take them directly to their own records via relationship; and trapping for Show All Records will keep them there.

This could also be done with a Find I suppose, but relational navigation is faster.

[raingirl]

This is not exactly what I was hoping for. I want to have one file with all People in it. Each office (admissions, college office, development, etc) needs to see different people. I want to build an separate interface for each office and filter just the people they need to look at. The "Show all Records" gotcha will be confusing. If the college office just needs 100 seniors and they hit show all records and see 20,000 alumni records, they will be thoroughly confused. I have several different people files in FM 6 and I was hoping to successfully consolidate into one file and filter the records through TOs. Am I missing something obvious?

[Fenton]

I was assuming from what you said and what you'd tried that you were talking about "restricting" records via access privileges, FOR EACH USER, not about general filtering. They have some similarities. I still don't know if you just want to present them with the records they want, or absolutely stop them from seing other records.

There's more than one way to do any of this. Which method you use depends on several factors. I would need a clear outline of what was needed, how many different types of people, what level of restriction, etc., before I knew which to use.

If you use record-level access for a GROUP of people, then you're going to need some way to identify them, and it's going to have to match, at the end, with an auto-entered field in the database. The Account Name itself will be too static, in my opinion; because you want to match several people.

You could use a field in a Staff file, referenced by Get (AccountName), or you could use a Privilege Set to identify them and their group's records. Both methods would work. A field in the Staff file is the most flexible, but may cause a small speed hit. Privilege Set would be faster, but would be less flexible.

There are some advantages to using the restrictions, as well as relational filtering. As I said, FileMaker automatically filters Finds when you're using record-level access. But it's iron-clad, so you need to know what you're doing; and even then it can sometimes get in your way. The "run with full access privileges" checkbox on scripts will usually let you bypass when needed.

It also causes some slow-down. It seems pretty good in 7. But still, if you're dynamically filtering 10,000 records, using a filter which based on an unstored calculation (at best), or also a relationship back to another table (at worst), it's going to slow down everything.

If you use record-level restrictions you become responsible for what they can and can't see. The method I outlined will NOT cause all records to be shown. They will never see <no access> records. That was the whole point. You must "trap" for Show All Records; ie., it must be a button with a script attached. It then goes to all THEIR records rather than ALL records.

Once you get into this level of interface control you can no longer allow users to have "All" Editing privileges, which allow all command keys. You must restrict them to Editing Only or Minimum. You have to give them buttons, even for New, Find or Show All. "All" editing privileges are very dangerous; Delete All Records, Replace, etc..