Debugging Scripts with Assertions – Access Control

Over the last couple of days we have come to understand assertion and have created a script that we can call when we want to assert. This requires just one line in our calling script – Perform Script specifying a JSON parameter with two elements, condition and message.

Required control

Today's challenge is controlling when assertions run. Assertions are a developer tool, not part of normal application behaviour. We need a way to control when they run.

On one hand, we can specify that the Assert script only continues if the current Privilege Set is [Full Access]. However, even developers will not want assertion turned on at all times.

The other factor is that a developer may want to test assertions while logged in with lower-level access. This is the same as being able to use the Script Debugger when not logged in with [Full Access].

With all this in mind, a standard user should never see assertion messages.

Basic method

The method of control we will use involves adding an exit point to the start of the Assert script. This is done as follows:

If [ // test if assertion state is OFF ]
  Exit Script [ ]
End If

The difference from here is how we test the assertion state. We will need a scripted process to set the assertion state on and off (Toggle Assert State). This script will only be available to developers.

Method 1 – Global

Our first method will be to use a global variable (or global field) to set the assertion state. The Toggle Assert State script will be:

#Toggle between assert state ON and OFF
Set Variable [$$ASSERT; Value: If ($$ASSERT; 0; 1)]

When the global variable evaluates to True it will be set to False; when False it will be set to True.

In the Assert script our test will be:

If [ not $$ASSERT ]
   Exit Script [ ]
End If

This method has the advantage of being limited to the specific session where the Assert state is set. It does not affect any other user sessions.

The other advantage is that the Assert state will be off by default at the start of a new session and the global variable dies at the end of the session.

Personally I would use a global field instead of a global variable. But that is my preference.

You will need to think about how to control access to the Toggle Assert State script. It will need to be granted Full Access Privileges to be able to run under all privilege sets. And it needs to be accessible to a developer who has logged in with a lower-level privilege set.

Method 2 – Persistent Data

Our second method will be to use the new feature in FileMaker Pro 26 - persistent data. We can toggle a persistent data entry in the Toggle Assert State script:

#Toggle between assert state ON and OFF
If [ GetPersistentData ( "ASSERT" ; "state" ) = 1 ]
 Configure Persistent Data [ 
       ASSERT ; 
       InstanceID: "state" ;
       Value: 0 ]
Else
 Configure Persistent Data [ 
       ASSERT ; 
       InstanceID: "state" ; 
       Value: 1 ]
End If

When the persistent data entry evaluates to 1 it will be set to 0; otherwise, it will be set to 1.

In the Assert script our test will be:

If [ GetPersistentData ( "ASSERT" ; "state" ) ≠ 1 ]
   Exit Script [ ]
End If

The issue here is that this turns on the Assert state for all sessions. We can limit that to [Full Access] sessions by setting the test to:

If [ GetPersistentData ( "ASSERT" ; "state" ) ≠ 1
     or
     Get(AccountPrivilegeSetName) ≠ "[Full Access]"
   ]
   Exit Script [ ]
End If

This still presents us with two problems:

1. the Assert state will be turned on for all [Full Access] sessions
2. there is no ability to turn the Assert state on for lower-level privilege sets

We can limit the Assert state to a specific device using the Get(PersistentID) function. This returns a unique text identifier of the device running a FileMaker client.

The Toggle Assert State script becomes:

#Toggle between assert state ON and OFF
If [ GetPersistentData ( 
     "ASSERT" ; Get(PersistentID) ) = 1 ]
 Configure Persistent Data [ 
       ASSERT ; 
       InstanceID: Get(PersistentID) ;
       Value: 0 ]
Else
 Configure Persistent Data [ 
       ASSERT ; 
       InstanceID: Get(PersistentID) ; 
       Value: 1 ]
End If

In the Assert script our test will be reverted to a simpler version:

If [ GetPersistentData 
     ("ASSERT"; Get(PersistentID) ) ≠ 1 ) ]
   Exit Script [ ]
End If

The persistent data entries for Assert state are now created and maintained in the file for each device running FileMaker.

The advantage of using persistent data to manage the Assert state is that the developer can turn the Assert state on, and it will always be on for all future sessions of that file on that device until they turn it off. The Assert state will be applied to any session regardless of privilege set.

Conclusions

I have presented here two methods to control the access to assertions in our scripts. Each method handles the required control in slightly different ways. Which one you use depends on the version of FileMaker you are using, and which makes most sense to you to use and maintain. Which did you prefer? I like persistent data.

Once again it is useful to know more than one method for any requirement. Then you make a decision as to which is the best to use for each use case.

Can you suggest a third method for managing the Assert state which satisfies the required control?