For us, one of the challenges with FileMaker Pro is the CUSTOM FIELD ACCESS PRIVILEGES area within the "Manage Security" area. We really need the ability to specify CONDITIONAL CALCULATIONS for custom field access privileges within the "Manage Security" area.

Right now, we only have the ability for a field to be "modifiable", "view only" or "no access". This isn't nearly enough. We need the ability to be able to specify a calculation to determine if a field is editable or not.

Imagine a scenario where you want an invoice to have all of its fields locked off as soon as the invoice is "approved" by management, except you still have 3 or 4 fields on the layout that are still open to all employees at all times (an "internal notes" field, a "UPS tracking #" fields, a non-global portal filter field, a "special notes" field on each individual line item, etc.).

Because FileMaker doesn't give us the ability to set custom field editing privileges based on a conditional calculation, we are often forced to use "custom record editing privileges" along with the "Get (ActiveFieldName)" function embedded within the "custom record editing" calculation window. Within the custom record editing privileges, we test to see if the user is in a specific field using the Get (ActiveFieldName) function, and then under additional conditional, we will allow them to edit the field.

For example, let's say that users are NEVER allowed to edit an invoice after it has been approved... UNLESS their cursor is blinking within the "Notes" field. We will setup a custom record editing privilege that looks something like this:

Case(

Invoice = "Approved"; 0;

Invoice = "Approved" and Get (ActiveFieldName) = "Notes"; 1;

1)

However, veteran FileMaker developers know that this will never work, because here is the problem: FILEMAKER WILL ONLY EVALUATE RECORD EDITING PRIVILEGES UPON OPENING THE RECORD FOR THE FIRST TIME. As soon as the user is able to edit the notes field, they can tab into any other field and edit all the other fields on the layout.

BUT HERE'S WHERE THINGS GET CRAZY: Line Items within a portal ACTUALLY DO RE-EVALUATE THEIR OWN CUSTOM RECORD EDITING PRIVILEGES WHEN YOU TAB FROM FIELD TO FIELD WITHIN A PORTAL!

So, if you have custom record editing privileges setup for your Line Items table based on the "Get (ActiveFieldName)" function, it works as expected!

In other words, LINE ITEMS WITHIN A PORTAL ACT 100% PERFECTLY THE WAY THAT WE WOULD EXPECT THEM TO ACT! Each field within a portal row continually re-evaluates its own "custom record editing privileges" as you tab from field to field within a portal row.

THIS IS THE DESIRED BEHAVIOR! The desired & expected behavior works perfectly when editing line items within a portal, but the behavior does NOT work as expected when editing the parent record!

So yes, you might give your users access to one field using custom record access and the Get (ActiveFieldName) function, but as soon as they can edit that one field, the entire record is open to them. So then we are required to use one of these workarounds:

1. Attach an "OnObjectSave" or "OnObjectExit" script trigger to each "unlocked" field, and then re-lock the record as soon as the user exits that field.

2. Create a brand new layout that FileMaker automatically switches to when the record is locked... turn off browse mode for the fields that can't be edited, and turn on browse mode for the fields that can be edited.

3. Create a brand new window that opens up when a user clicks on one of the unlocked fields, and let them edit the values there via global fields or some other mechanism.

4. Custom field validation attached to each field, to evaluate whether that field can be edited or not.

All of this is a lot of extra work, and potentially fragile if we forget to set just one script trigger. It also could potentially give the users an experience that isn't as user-friendly as we would like.

So, to reiterate what I mentioned above: If you set custom record privileges to a child record that you are viewing within a portal (such as an invoice line item), FileMaker PROPERLY RE-EVALUATES THE RECORD PRIVILEGES FOR EACH PORTAL FIELD THAT YOU TAB INTO! So FileMaker ACTUALLY WORKS IN THE EXPECTED WAY when you tab from field to field within a portal row! Each field re-evaluates its own record access privileges! This is how all record access privilege should work throughout the entire system: on both parent records and child records.

If not, then the ultimate solution -- and the easiest solution -- would be for FileMaker Inc. to simply give us TRUE CUSTOM FIELD ACCESS PRIVILEGES that re-evaluate upon entering each field. Otherwise, we are stuck using record-level security (which doesn't really work on the field level because FileMaker doesn't re-evaluate security upon entering a new field. It only re-evaluates upon entering the record after it has been previously committed).

Interesting observation, I hadn't noticed that previously. I'll have to experiment with it.

scottworld If you need an immediate solution to this problem, you've really answered your own question. Move the fields that you need to be able to edit into a different table that is connected to the parent with a one to one connection. In the first instance, you get to have a different privilege set, and as you've noted, by placing these fields into a portal ( maybe you only need to place the fields ) you'll also get the "desired behaviour."

Wow, it works! You just have to put the related field on the layout -- doesn't even need to be in a portal! Amazing discovery, Malcolm! This little trick actually gives us TRUE custom field level access control! Thank you for this hot tip!

FILEMAKER WILL ONLY EVALUATE RECORD EDITING PRIVILEGES UPON OPENING THE RECORD FOR THE FIRST TIME. As soon as the user is able to edit the notes field, they can tab into any other field and edit all the other fields on the layout.

BUT HERE'S WHERE THINGS GET CRAZY: Line Items within a portal ACTUALLY DO RE-EVALUATE THEIR OWN CUSTOM RECORD EDITING PRIVILEGES WHEN YOU TAB FROM FIELD TO FIELD WITHIN A PORTAL!

I'm guessing that this behaviour is completely consistent. Let's say Rule #1 is "only evaluate record editing privileges upon opening the record." You open a record on a layout that contains a portal. That record is opened and rule #1 is put into action. The portal displays the related records. However, the portal records are not open. They are visible, in the same way that many different records are visible in a list view. But, importantly, they are not open. If you click into a field in a portal, that record is opened and Rule #1 is put into action. If you click into a different portal row, the last record is closed and the new record is opened: Rule #1 is put into play. If you click into a field in the main table, you exit the portal record. You modify the parent record, then go back to the portal and enter a field, Rule #1 is put into action.

Well yes, that would make sense if you were clicking from portal row to portal row (because those are different records). But it still works if you simply tab from field-to-field within the EXACT SAME portal row (i.e. not switching records at all), which is really the amazing result that we wanted to achieve! Same thing if you simply tab into or out of a related field that ISN'T within a portal. This is a great discovery, and I hope that FileMaker doesn't change this behavior because they think it's problematic -- this is actually desired behavior that should just be rolled out to EVERY type of field.

Actually, I was going to advise to move the notes field to a different table, but not because of this different evaluation of privileges in related records, but simply because you don't have the same rule for this field, which indeed is a clue that you should have two tables.