There are a number of account related script steps that you can script into your solution:
"reset account password" and "change password" are two of those script steps.
If you check off the box "run script with full access privileges", then you can have any permission user run those without granting full access privs.
The other option is to take all account management out of FM and use External Authentication...
Thank you Mike for pointing me to the right direction...
As you suggested I created the script step...but not working as I expected...
Reset Account Password
Run script with full access privileges "checked"
This is what I expected, will happen when I run it:
"Reset Account Password" Options Window will open up
Prompting me to enter the Account Name and New Password
When I run the script, nothing happens... No account re-set window pop-up..
Please let me know what I am doing wrong....
Yeah, I would have expected that script step to present the dialog box too. But from the help documentation...
"This script step resets the account password without displaying a dialog box."
So how about presenting your user with a Custom Dialog box that allows them to enter the Account Name and new Password into some fields. Then specify these fields in the Reset Account Password step?
The way I handle it is I have a user table and an "Admin" screen lists all of the users in that table. On each row there is an a reset password button (among other admin functions). When the admin clicks the "reset password" button it runs a script that has the following steps:
1) Set a variable with a temporary password. It can be something simple like their user name or more complex like Right ( Get ( UUID ) ; 8 )
2) Run the reset account password script step that sets the user's password to the value in the variable with the "user must change password on next login" checkbox checked.
3) Email the user their temporary password (still stored in the variable) with a notification that they be asked to change it on their next login.
Even though I call it an Admin screen the users that access it don't have full access privilege. The script are just run with full access. You may be able to adapt some of that technique. I also a button use the same screen to enable or disable accounts.
All suggested solutions are great, but I would like to add a small comment, coming from my own experience:
It looks like a good size organisation (150 users) with their own IT department, so why it is only you who has Full Access? Someone in IT should be sensible and technical enough to have Full Access and be able to re-set the passwords. They probably do not know how, but you can create a document explaining it. Even if IT does not use their access, it should help you to maintain the relationships with them, because I am sure, they will hate a system they do not know and do not have access to.
I worked for FileMaker development companies before and I am in IT now. I do not remember any clients where IT would not have Full Access to FileMaker systems, although I m sure there is good reason for this. The only exceptions were closed "packaged"/"of-the-shell" solutions, but then you would not expect their developer setting up your users.
I'll say it again: 150 users just screams for External Authentication so that IT (who manages the directory service) has full control over the accounts without ever touching FileMaker.
I agree with Wim, this is much better solution ( "Like" is on the way)
IT will feel in control and trusted as they can assign full access privilege to themselves if needed, even though it is unlikely they will ever use it.
They can manage users, use their standard support system for tracking and at the same time they use the tool they are familiar with to manage accounts.
Finally, if it is really necessary, you can setup the authentication, where IT will be able to manage through Active Directory all accounts apart from Full Access without having Full Access themselves.