Controlling field level access within a table in a clean way that allows you to make it vary between records is something that can't be achieved seamlessly with built-in Record Level Access controls - and if security really matters (and why else would you do this!) I'd counsel against using custom menus or script triggers to 'fake' it. These are interface techniques that can relatively easily be bypassed by someone with a little know-how.
Instead, I'd suggest you consider providing users with edit privileges for those fields they will *always* be permitted to edit, then provide an alternative mechanism that allows them to edit other fields based on other conditions. One way to do that would be to provide an over-ride script that checks that the over-ride conditions are met and if so pops up a ultilty window (or custom dioalog etc) where the user can edit the otherwise uneditable values. Then the script (set to run with [Full Access] privileges:
...can take the edits the user has made and apply them to the substantive record.
Once caveat is that you should consider having the script open the record (and trap for an error) before allowing access to the edit process, to prevent conflicts that might arise if more than one user attempts to edit a given record simultaneously. Doing that will allow record locking to apply to your 'special' override edit procedure in much the same way it does in other situations (ie the record will be locked during editing until the script commits the changes)
It's unlikely to be more work to set up the way I've described than a bunch of script triggers and custom menus, and it should be possible to work it into the interface in a way that is fairly smooth and intuitive for users - however the result will be secure and robust.
R J Cologon, Ph.D.
FileMaker Certified Developer
Author, FileMaker Pro 10 Bible
NightWing Enterprises, Melbourne, Australia
if the customer is ACME, the user can edit all fields; for all other records, the user can only edit some fields
Perhaps you could keep some fields in another table, with a 1:1 relationship between the two.
Wouldn't just two separate privilege sets with custom privileges assigned at the field level resolve what you're trying to accomplish? You could also approach it from different layouts depending on the privilege set. Another option, depending on exactly what you're trying to accomplish, would be to control the find function to limit the returned set of records to be limited to a particular user. I've seen this a few times in sales organizations where they don't want a salesperson looking into other accounts that don't belong to them.
I assume you are using a calculation as part of the privileges definitions to achieve this. Show us the calc you are trying so we can see what is actually happening.
Give some details of what might be in the data if specific fields are used in the calc. Remember that such calcs must resolve as booleans: true or false are the only useable results (T/F, 1/0, value/null, etc).
Calculations for record-level-access (RLA) are evaluated from the software's [Full Access] perspective, so you cannot use
"current" privs as part of that calc.
While you could make more than one privilege group, you can only assign an account to one of them, so the conditional aspect would be lost for any single account, thus the need for a boolean calculation.
Thanks everyone for your help!
I have not yet gotten a chance to work on the file, but when I do I will report back.