Please improve FIELD ACCESS PRIVILEGES by adding conditional calculations

Discussion created by scottworld on Aug 31, 2016
Latest reply on Sep 1, 2016 by Fabrice Nordmann

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:



Invoice = "Approved"; 0;

Invoice = "Approved" and Get (ActiveFieldName) = "Notes"; 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.




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).