There are 2 techniques described here:
Instead of checking the status as described in this post, your button script can set a variable to 0 or 1
from the post...
my full calc for limited edit permissions is as follows
global::g_permissions projects = "no" ; 0 & S4HU_EventScript( "gui.fp7" ; "permissions error" ; "" );
project_status = "invoiced" & global::g_permissions projects creation = "no" ; 0 & S4HU_EventScript( "gui.fp7"; "lockout error" ; "" );
project_status = "delivered" & global::g_permissions projects creation = "no" ; 0 & S4HU_EventScript( "gui.fp7" ; "lockout error" ; "" );
Case (global::global edit mode = "no" ; 0 & S4HU_EventScript( "gui.fp7" ; "edit mode warning" ; "" ) ; 1 ))
I use a single permissions set for all my users that relies on globals pulled from a user table that dictates permissions. Then I use an opening script to find the user record based on the user account name. The opening script populates all the globals required for the permissions set. This approach allows you to create a solution that moves the permissions to a custom built FMP layout where selected end users can create new accounts and edit permissions. The developer can then lock out the actual FMP accounts / permissions. Ultimately making the solution easier for the end user because they require no knowledge of how FMP accounts and permissions fucntion.
In the above calc the first condition of the case statement tests to see if my user has general permissions to edit project records. Then it tests to see if the individual record status allows editing. When the statment fails the event script plugin then activates a script that describes the error to the user (either lack of permissions or record locked out due to status)
Then the second case statement requires the user to have activated an "edit" button on the layout before being able to edit the record (again activating a script through the pluging if this statement fails).
For end users unaccustomed to databases and the find capabilities I've found that often the user will change a record by mistake when intending to do a search. The edit button does a lot to keep this from happening as they are forced to be in "edit mode" to change the record.
Overall this solution gives you 3 levels of record locking (user based, record based and "edit mode" based).
Hope this helps.