Do you ever look back with fondness on the days when adding a new user to your database required you to ask all users to quit FileMaker Pro, then shut down FileMaker Server so you could re-open the database directly in FileMaker Pro, then enter that new user in every single file of your complex, file-laden solution? FileMaker Pro 7 brought an end to the not-so-good old days of FileMaker Pro account management. Now administrators have full access to accounts and privileges for files hosted by FileMaker Server 8 or FileMaker Server 7, and even better, it's now possible to manage accounts using scripts, which makes it a lot easier to maintain multiple user accounts across a multi-file FileMaker Pro solution.

This three-part article series shows you how to create an account management system that takes a little effort to put together, but it's highly portable and after you're done, you'll be able to move it to any database solution you create with little modification. In fact, with FileMaker Pro 8 Advanced, you can cut and paste all the necessary components into any solution in short order. In the long run, creating a system such as the one I describe can save you a lot of time if you have a large number of accounts to manage, and it ensures consistency across files. If you step back from the instructions, you're also likely to learn advanced techniques for creating modular, reusable routines you can apply to a host of other database architecture and programming problems.

The first article of the series includes a brief primer on scripting account management, an outline of the account management solution this article will help you create, and an introduction to the interface for the solution. The second and third installments will provide a detailed look at all the scripts involved with the account management solution, giving you insight not only into account management, but also into segmenting scripts and structure to maximize efficiency and make your solutions more portable.

It's possible to create and authenticate accounts outside FileMaker Pro using Active Directory in Windows or Open Directory on Macintosh, but often this approach isn't viable for various reasons. This account management system is for administrators charged with managing multiple accounts across multiple files. Although it isn't a user solution, you can adapt the techniques and principles I'll show you to create a scripted, user password change routine. Finally, this solution is designed for a single administrator to manage many accounts at a given time, but you can adapt it for the unlikely scenario that more than one administrator must create and manage different accounts at the same time.

What's possible

When you're finished putting together this solution, you'll have an interface for account creation and deletion, account enabling and disabling, password resetting, and even changing user privilege sets. The only Accounts script steps I don't cover in this article are Re-login and Change Password; the latter provides an interface for users to change their own passwords, whereas this solution accomplishes something similar with the Reset Account Password script step. Figure 1 shows the main account management layout that gives an idea of the finished solution. It isn't difficult to adapt the solution to batch account creation and deletion, and as I mentioned, you can apply what you learn here to creating an interface for users to change their passwords.

I've designed this account management system to handle groups of accounts that fall within uniform privilege sets. You must mirror privilege set names -- but not restrictions -- across all files in your solution. Accounts fall under privilege sets that share the same name across all files, so if you want a particular user to have special privileges this model can't handle, you must manage that account manually. You can handle the vast majority of accounts and privilege sets uniformly, so this task shouldn't pose much of a limitation.

It isn't possible to use scripts to add, delete, or change accounts attached to the [Full Access] privilege set, but fortunately, most solutions only have a couple of full access accounts, so you must manually create them in each file even if you use Open or Active Directory to authenticate the other accounts.

The approach

The order in which you construct this solution makes a big difference in how quickly you get to the testing and deployment stage. Before I get to the details, here's a brief overview. First, you choose a Master File in which you create an Accounts table that lists the account names in your solution. Then, create file references to that Master File in each of the files in your solution, along with a "utility" layout in each file that displays the fields in the Master File's Accounts table. Next, create privilege sets in each of your files, then create the user interface layouts in your Master File, along with "control" scripts to run the solution. Finally, copy five key scripts into each of your files. Figure 2 shows a graphical outline of the solution.