As FileMaker developers, we take a lot of things for granted. For example, FileMaker’s Browse Mode/Find Mode feature is actually pretty slick; just place a field on a layout and it becomes both a data-update field as well as a query field without additional coding. However, when a layout is set to “save record changes automatically”, the frequency of people thinking they are in Find mode when they are actually happily clobbering data is enough to drive the most laissez-faire FileMaker developer nuts.

Sometimes, calling such problems “training-issues” just isn’t enough.

One solution is to roll your own Edit Mode feature. This technique uses the power of global variables in FileMaker 8+. In this example, I am going to combine scripts, a global variable and a custom privilege set to regulate users’ record-edit access.

Note: this article in intended to illustrate a general technique, do not rely solely on this example to secure your database.

The screenshots below are from a Mac but this tip is platform-agnostic.

Download the Example File

Note: the top level account is “admin” with no password

Step-by-Step

1. Create the table
In this example, I am going to start with a new file. I have defined a table called “contacts with a few basic fields.

Don’t worry about the “lock status” field for now; that is an interface bell-and-whistle that I added to give the user some visual feedback. Check out the example file to learn more about that later.

2. Create the “toggle” script
Next, I am going to create a basic script that toggles the edit mode. The script is going to use a global variable as a switch. It sets a global variable to either 1 or zero each time the script is called.

I have chosen to name my global variable switch $$__locked but you could call it whatever you wish. Just make sure it is a global variable because we want the variable to hold on to its value after the script is run.

The script works by checking first to see if $$__locked is “on” (i.e. has a value that isn’t zero or empty). If $$__locked is “on”, the script turns our switch “off” by setting $$__locked to zero.

3. Configure record level access

We need to tell FileMaker to check the global $$__locked before allowing our user to make record changes. Since record access is controlled by FileMaker privilege, I am going to go over to the Define>Accounts & Privileges… menu and create a User account with a custom privilege set called “User”…

To configure the record data access setting, I select ‘Custom Privileges’ from the ‘Records’ pull down menu of the ‘Edit Privilege Set’ screen…

I am going to control access to the “contacts” table by highlighting it and changing the ‘Edit’ privilege to ‘limited…”

My goal is to use a calculation expression to govern the user’s record modification activity. Records can be edited when:

not $$__locked...

FileMaker will evaluate the expression not $$__locked each time the user tries to modify a record. If $$__locked is zero or empty, the expression not $$__locked will evaluate to true (not locked) and the user will get to edit records. If $$__locked is “1″, our expression will evaluate to false and our user will be blocked from making any changes to ‘contact’ records.

4. Bells & Whistles

In the example file, you’ll note that I have added couple of simple re-login scripts to toggle between my “user” account and my “admin” account.

Finally, let’s cap it off by attaching a button to our script and by adding a “lock status” calculation field to create a simple indicator of the record lock status.

Cheers!