Have you created Account Names and Privilege Sets in Filemaker itself? Why not use those to grant the required permissions?
I would just use the Manage Security to do this. Give everyone a user account, and assign privileges to delete in there.
I have made accounts with the manage security, however the way I want to set this up is to be able to call the system admin or manager over to see why the user wants to delete a record with the aid of dialog boxes.
I don't want to completely remove the function of deleting for a user but to put a safety barrier round it which will allow them to discuss why it needs to be delete with someone who understands consequences of losing data.
As we need a Users module for contact information and holidays already I don't see the harm in storing a password which ill make exactly the same for the filemaker security password.
I've created the script now and it works.
Just a thought: Have you considered emailing a snapshot link and explanation to the manager? That way the manager could handle it without even calling them over, and handle it while already logged in with their own creds.
Also, while a users table is often needed (for more details about the user) that doesn't mean you need to (or should) store the password. You could just store the username. Also, with the exception of full access privileges, you can script the adding and updating of user accounts.
Just thoughts, for what they're worth.
Another option is to provide a field like a check box field for deleting. This wouldn't actually delete the record, but just mark it for deletion. Then later on a admin can find and review these records and delete the ones that are ok to delete. You can also use the check box to omit them from finds, so from a end user perspective the record is no longer available; without actually being deleted, until the admin says so.
Absolutely use the security and access privileges.
Bonus points can be gained for setting up extended privileges, and using these to flag when privilege sets can and cannot do things such as delete records.
There have been some good suggestions provided to you.
You should use the security and access privileges. Depending on the complexity of your solution, another option would be to set up a Delete Table to hold the deleted data. Then the supervisor could review that Table of deleted records and then delete from the "Delete Table" without having to wait for him/her to review the record first.
If you go the route of a delete table also create a process to re-create the deleted record for when the supervisor does not agree with the record deletion.
Some business rules will always keep the deleted data in that "Delete Table".
Unfortunately, there's not a good way of incorporating strict security privileges with a convenient dialog.
It's universally considered bad practice to store account passwords within FileMaker itself. There are clear security issues and some development ones (what if someone wants to change their password? you've got to coordinate between two places now). There are ways to mitigate the potential threats (namely preventing anyone except specially authorized privilege set from having access to that table, but it's still a Bad Idea.
Another way to mitigate is to have the "delete password" different than the actual login password.
So, if you're going to store a delete password, make it different than the manager's actual password and limit access to that table to Managers or above only.
One of the first thing I always do is create a custom key command set with the default key commands mapped to Filemaker Scripts that perform the New, Delete, Duplicate, Print, Find, etc. In that way I have total control of what happens when a user clicks any of these buttons.
You can do all kinds of conditional deletes (like if the record was made by the same user, not older than a day, etc, or store the 'deleted' record somewhere) and same for New, Duplicate, etc.
Then in the Users table I'll give the admin the option to set for each user what he/her can do in each table if needed. So per user the admin can choose and easily change if a user can delete, new, duplicate, etc.
I find this much more flexible than creating access privileges for each possible permutation of user privileges. I totally agree that you shouldn't save passwords in FM but link the FM users table to the FM users. But instead of making a lot of different access privileges sets I only need a couple for the main roles in the organisation. (typically full access, normal user access, web access) which are then assigned to the different users. You can script all that.
The rest is dealt with in the New, Delete, etc. scripts. Super flexible, total control over messages and choices for the user, and very easy to manage and change afterwards.
My 5 cents...