If the record modification privileges were set to:
wouldn't that do the job? or do I misunderstand?
I'm assuming that you have the shift in one field and the student name in another. Connect the student name field to the OnObjectEnter script trigger. The field will open for editing (it is a post script trigger) but then a script will execute. The script will determine if the field is empty or if a student has already signed up for that shift. If the shift is free, the script will do nothing and the student can enter their name. However, if the field is not empty aka someone already signed up for the shift then the script will close the record thus preventing the student from making changes.
The script would be:
If(IsEmpty(field for the student assigned to shift)=0)
Custom Dialog ("You may not alter shift currently assigned")
If the shift and the student working it are in the same field this idea will still work but the IF statement will be more complicated.
Assigning script triggers:
Right click on the field in layout mode
choose "set script triggers"
click the box next to OnObjectEnter and you list of script will appear
Highlight the one we just created and click ok
Click ok again
The field should now contain a small red star in the corner, this means the trigger has been assigned.
Let me know if you have any questions.
Excellent! Thank you! :)
One final detail.
Can we make it so an admin can alter the record?
Do I simply add another condition to the IF statement like this?
(or something like that?)
If the workers log in using one privilege set (with the record modification restriction), and the admin logs in using FullAccess, this is already a done deal. Full Access does not have the IsEmpty restriction, only the workers, thus FullAccess can change whatever fileds they want.
Just my opinion (and shared by quite a few others who've posted on this topic...though not this particular thread), but handling access and security through scripts is far less secure than using the accounts and privileges system inherent to FM.
This situation should be handled through accounts&Privileges, not a script.
One for Data entry - admin users all fields with allow field entry [on]
second for Read Only any user. All fields you wish to protect with allow field entry [off]
Hide all layouts from status area
navigate with scripts
If Get(AccountName) = "Admin"
Go to Layout Edit
Go to Layout Read Only
You should know that is not really a secure solution... ;)
If the default log on account is Guest and
You have to pass a log on test to get into a file. Where each user is assigned a
level of security, it is more secure then 3 user accounts of Admin, Edit , Read Only.
Editing is based on the users table and by the user who is currently logged on.
See Admin panel
I could go on about log on proceedures on how to superdeede FM native accounts , but that would give secrets.
I totally agree with John. Using a layout to restrict privileges just isn't secure and neither is developing one's own account and login process.
..........and neither is developing one's own account and login process.
Meaning accounts & privileges? Or were you referring to something else?
I agree that nothing is "==secure", but is not the "account and login process" provided in FMP the current best practice since it is the most secure of the available options?
Perhaps I am misunderstanding your post...please feel free to explain.
Edit: I re-read it and re-read it and finally 'got' the "one's own". This would be as opposed to the process provided by FMP. Sorry for being slow...I agree with you LaRetta.