Data Separation and Account Security

FileMaker’s built-in security features for accounts and privilege sets are flexible and robust enough to meet almost any need. There are times, however, when a particular scripted process needs to override an individual’s security access in order to complete its task. In most cases, the option to ‘Grant Full Access Privileges’ to individual scripts has met this need. (Note: this option should still be used sparingly and only when absolutely necessary.) There is, however, an instance where this doesn’t work as expected, and that’s with data separated apps.

Data Separation and FileMaker Security

Data separated apps are becoming more common, and offer some great benefits to developers.

For example, by separating data from the UI, you can deploy updates to UI files without needing to migrate data, which is useful for vertical apps. Once you’ve established a data separated model, you’ll need to consider security for each file.

Let’s dive into your security settings for these two files:

Data File – Account

In this example, we’ll be creating a new user ‘Test Account’ and assigning them to the ‘Basic’ privilege set.  

Data File – Privilege Set

We’ll configure the ‘Basic’ privilege set to give users the ability to create and edit records in all tables, without the ability to delete. You’ll see that layouts are view only, value lists are view only, and scripts are executable only. Since most of those elements will live in the UI file, these settings work fine here.

UI File – Account

We’ll also create an account for our new user ‘Test Account’ in the UI file, and assign them the same ‘Basic’ privilege set.   

UI File – Privilege Set

I’m going to configure the ‘Basic’ privilege set differently than we did in the data file. This demonstrates that record-level security settings in the UI file do not impact record-level security settings in the data file. Here, this privilege set gives the user the ability to create, edit and delete records in all tables. Layouts are view only, value lists are modifiable, and scripts are executable only. In short, the user will not have any development capability, but they should be able to work within the system freely.

Granting Full Access to Scripts Has its Limits

Traditionally, most scripts will live in the UI file since this is where layouts are loaded, buttons are clicked, etc. In this example, we have a ‘Remove Duplicates’ button that runs the ‘Duplicate Cleanup’ script that will delete all records marked as a ‘Duplicate’.

We want this script to run regardless of the user’s security privileges, so we’ve enabled the ‘Grant Full Access Privileges’ option.

Unfortunately, when we run this script as our ‘Test Account’ user, the records marked as duplicates aren’t being deleted! What went wrong?

As mentioned before, scripts with the ‘Grant Full Access Privileges’ option enabled can override the user’s record security settings, but it can only override the settings in the current file. Now that our task data lives in the Task Data file, it’s the data file’s security rules that will determine the rights of the script to add, edit or delete records. This means that if your script is in the UI file, it will not be able to override the user’s record level security settings in the data file, even with ‘Grant Full Access Privileges’ enabled. This can be an unexpected result at best, and a major cause of issues at worst.

The solution is simple, although not ideal: move the script to the data file. The UI file can perform scripts from the data file, so the real hurdle will be recreating the necessary context needed for the script to perform its task.

These are things to keep in mind when deciding if you want to develop within a data separated model. If you’re already working with a data separated system, be sure to plan ahead for these types of scenarios.