Clicking on a dropdown with my mouse is not a keystroke....
I would suggest that you determine the rules around when a record is "final" (either an algorithm or a human action) and have that set a field to "Final".
Then use user permissions to limit editing of that record based on whether the Table::Final field equals "Final".
That will not use as much resource as an ongoing script, and achieve the total lockout that you seem to be looking for.
Note that an algorithm can be easily tripped...and locking out the user prevents them from fixing a typo...consider this as you determine your lockdown criteria.
Very interesting suggestion. I'll check out how to achieve this "limiting edit permission" and then come back.
In the meantime thank you very much for your thoughts.
Don't overthink it too much. Use FileMaker's built-in security tools. Users should be assigned to a privilege set that prevents editing based on a condition - field "lock" = true/1/whatever value to indicate it is now un-editable.
Be sure to have some way to toggle the lock field back to an open state as mistakes will happen. This should not be pubic knowledge with only admin level users having the ability.
If you're using script triggers, any items the do not fire with a keystroke trigger should have a different trigger applied to those elements - on enter, modification, etc. It sounds like a single trigger type will not work for all scenarios in your application. Don't be afraid to combine them, just make sure your triggers don't trip over each other.
I found information about creating privilege sets but no place yet to define a condition.
keep reading up on the security settings its in there.
You have to drill down into custom record level settings
Okay. Thanks. I'll keep reading.
In the Security windows...
Select the table, then down on the bottom under the edit column you have the choices Yes, Limited, No
Limited...pulls up the calc window for you to define HOW it is limited....your algorithm goes there...
To get to the dialog that Eric is describing, select "custom privileges" from the Records Menu inside the privilege set dialog.
I have no problem with the privilege settings path already advocated by others, but add a couple of other points:
1. Script triggers only work on the specific field/layout/object instance where the trigger is applied. If a field can be accessed on another layout or another instance where the trigger is not used, the triggered script will not run. So … don't put all your faith in script triggering.
2. With something as vital as key invoice details, I would use field validation to lock the key data fields in the invoice so that nobody can edit those fields in any context (but even so, applying what David suggested above: "Be sure to have some way to toggle the lock field back to an open state as mistakes will happen. This should not be pubic knowledge with only admin level users having the ability."). I use this method in a cashbook database where certain details must not be altered if particular conditions have been met—e.g. once a transaction has been reconciled to a bank statement. The validation by calculation calc is simply: If ( yourLockFieldName = 1 ; 0 ; 1 ). If you need to lock the field in more than one instance, as I do, you can use a separate lock field for each instance: If ( lockFieldOne = 1 or lockFieldTwo = 1 or lockFieldThree = 1 ; 0 ; 1 ).
I found the "security settings ..." and tried it. It currently locks me out from any modifications. But that is certainly due to the condition I checked. However, it says "you are not allowed to edit ...." which is in a way misleading. I have no way of telling the user that the invoice is final and my not be altered anymore.
So I followed the other route and used script triggers for any field other than edit boxes. That works for the moment but is a bit cumbersome. I need to remember to use a script whenever I add something to the layout.
Using field validation is an interesting thought, too. I will check this out. If I can get it to work properly, this seems the to be the way to go for me. I'll let you know how it goes.
Thank you all very much for your valuable thoughts. I learned a couple of interesting things from you.
I'll keep you posted.
You could have a field or a text with conditional formatting on the header of the layout. The field could display 'Final - no changes' or whatever, the text could display the same, visible only when the 'final-condition' is set
Then, the message 'You are not...' would be in that context, could make more sense..
You say "I have no way of telling the user that the invoice is final and may not be altered anymore". When you look at field validation settings you will notice that you can word your own message that users will see if validation fails—in other words, if they attempt to edit a field which is locked.
That was related to the "security ..." solution. Of course with field validation I can use my own messages.
Thanks Markus. Interesting solution.