You can do this with a Privilege Set in Security
To expand upon the privilege set idea...you'd need to set your "admin login" users to a different privilege set than your standard employees. Then, upon either layout load, or filtering of records, etc (depends how you've built your solution), you'll either show a layout with access or not based not only on the privilege set but also if the container field with your signature is empty. You can have a special layout that displays the data, but there's not browsable access, or you can completely deny entry, etc.
Doing this in the accounts and privileges area is a better way.
Select the table in question, and set the user's "Edit" privilege to "Limited.." and use that calculation to see if the signature field and/or timestamp field are empty.
I disagree. Your method will certainly work, but it has it has flaws. The user will be presented with "No Access" in the fields and/or FileMaker-esq validation warnings. The user experience is always an important consideration and you've ignored that.
You probably also want the record locked for other users?
One consideration might be to not let anyone have editing privileges and use a global for entering the value with a script setting the field value and assign the script full access privileges. The script can check first for previous data entry, etc.
Using the globals allows the user to NOT enter the data should there be an interruption and to only enter the data via set field after the data is checked and approved. This will preserve the get(serialid) values as no record would be created allowing you to check for missing records.
Or if there are only three or fewer fields you could use the show custom dialog to enter the data in the fields.
Set script to full access otherwise everyone other than admin and full access cannot modify record
show custom dialog
if get(lastmessagechoice) = 1
revert record <--- this will not advance te get(serialid)
"The user will be presented with "No Access" in the fields..."
This need not be the case. Locking a record so that it cannot be edited will not bring up "no access" screens--only happens if you lock the record so that it cannot be viewed. And there are simple methods available to hide such records when you do block "view" access. You can likewise steer users away from actions that trigger error messages.
Lock your data down using access privileges, then work out interface designs to improve the user experience.
I disagree with your disagreement...LOL
If you set the "View" access to the calculated privileges you are correct. but I would not do that.
I would set the "Edit" privileges to the calc and leave "View" set to "All".
<<No Access>> would not arise since they have permission to view...just not to edit.
1 of 1 people found this helpful
Typically, when a client of mine asks for "locked", this means not viewable. However, if in this case the user still needs to view, just not edit, then you're right, "<No Access>", will not appear. As "philmodjunk" indicates, some additional UI features are necessary beyond mere security setting adjustments to yield the desired UX.
The topic of whether or not all of your access privileges are solely handled via FileMaker's native interface is a lengthly discussion in and of itself.
Note that when users are not allowed to view certain records, a simple find--either performed by the user or a script automatically omits "no access" records from the resulting found set. Thus, it's pretty easy to improve on the user experience by hiding them away from the user.