ncluding that these users have traditionally been able to create/edit layouts, so they could bypass layout-based 'tricks' (which are not really security.
The abiltiy to create and edit layouts is very much part of the privilege set and not a "layout trick"
So before you tackle anything else you need to tackle this. For all we know user can also create new priv sets, scripts, other accounts,... So fix the basic priv set for users and let us know what that is and then we can help you with the other things
You're correct, a lot of the general users are because they just didn't know any better. I've told them that this has to change, and they're OK with that. I will certainly be able to give the users somewhat restricted access to RECORDS with privileges, but I suspect that they are going to be wanting to let users create their own new layouts and tweak existing ones.
That means any of the methods which involve setting fields as buttons or layout/field-based script triggers that help us limit a user's ability to enter a field or change a record are not going to be very useful. That's the reason to focus on privilege sets and RLA. I've also seen some old notes on field validation calculations and though the validation failure message is pretty limited and usually not very informative, that may be the way I end up going.
I was sort of hoping that I could somehow create a list of fields that become uneditable when the contract goes from Draft > Executed and another list for Executed > Paid and then stuff that into the 'Allow records to be edited when...' calculation that would be able to know which field the user is trying to edit.
I know about a much more complicated scheme where you set up 1-to-1 tables containing the fields you want to limit, but I'm afraid that it is going to be way over the head of the person doing day-to-day maintenance and minor changes to the files.
-- Drew Tenenholz
Disregarding the layout trick issue, I addressed exactly that scenario in a cashbook application, where it is essential that once an item has been reconciled the amount and certain other data must not be changed, then once it has been reported for tax purposes other data such as expenditure/income category must not subsequently change. The technique I applied is:
1. Create one or more boolean Lock fields, which hold a 1 if relevant condition are met, otherwise empty.
2. Set the fields you want to lock down to validate by calculation so that if the relevant Lock field contains a 1 it cannot be altered.
I'm sure you could adapt that sytem to suit your case.