The Requirement

The client that manages their business processes via a set of FileMaker files, has different access levels for different users based on their specific assigned roles. The client has a demand to restrict access for specific users, to lock a record immediately after they create it. Once the record is committed and accepted, it cannot be modified. Here is an approach that explains how this was achieved for designated users.

The Process

FileMaker has built-in security feature to manage uncompromised access. To assign access to users with only create access and no modification access, a new privilege set is created under ‘Create Record Privileges’, with ‘View’ and ‘Create’ set to ‘yes’, and ‘Edit’ and ‘Delete’ set to blank as shown in the image. Field Access privileges is set as per requirement, in this instance, ‘Field Access’ is set to ‘all’.

In ‘Edit Privilege Set’, ‘Layouts’ level privilege is set to ‘All modifiable’, while ‘Value Lists’ are set to ‘All view only’ and Scripts set to ‘All executable only’. The ‘Available menu commands:’ is set to ‘All’.

By following this approach, users with Limited access can create records and edit records that are created during the current active user session. Any other records created in earlier sessions, users do not have access to edit.

However, the catch is that this approach makes new records created during the active user sessions editable, which was not the specified requirement.

To be in par with client expectations, security settings were tweaked, restricting access to edit new records immediately after creation. The limited value under the Edit option was selected, with a condition so that only users with a specific privilege set can edit the records, in line with the client requirement.

However, we discovered that this setting can vary as per the client requirements, and this approach may not always work. Consider a scenario where a user mistakenly commits a record. In this case, they won’t be able to edit the record again. Here is a probable solution.

The Global Fields

Global fields can be used to collect data temporarily through a separate Form. Data is saved using a script that is executed through a button. A confirmation can be obtained to save data along with a warning, indicating a record that cannot be edited once it is created. This way, users can decide when to save data.

FileMaker security settings, along with the Global fields give the expected results. For more information, feel free to contact our FileMaker experts.

Demonstration

The example we will be using is a follow-on from the previous article, in which we showed a method for displaying data of companies and contacts. We displayed the FileMaker data in a jQuery datatable in the FileMaker Web Viewer, which allowed us to include jQuery features like pagination and sorting without any coding. Using the FileMaker.PerformScript() function, we can add the functionality through which, once the user clicks on any of the contact records from datatable in Web Viewer, the chosen contact details are shown on the FileMaker card window.

The FileMaker.PerformScript() function takes two input parameters:

1. FileMaker Script Name – A non-case-sensitive name of the script we wish to run
2. Script input parameters (optional) – a string that contains the required parameters, which can be read using the function Get(ScriptParameter).

This FileMaker script can be called from the WebViewer using the following JavaScript function: function performFileMakerScript() {
FileMaker.PerformScript ( “FileMaker Script Name”, “Optional Parameter” );

The highlighted section from the above screenshot shows how to call the FileMaker script using ‘FileMaker.PerformScript() function from Web Viewer. In it we write a JavaScript function called showContacts(), in which we can specify the execution for a double click event. We specify that a double click event calls the FileMaker script called “Show Contact Details”, passing the ID parameter as the optional second parameter. The ID parameter is retrieved from the double click event, by identifying the datatable row that has been clicked. This id parameter is further used in the FileMaker script to get more details of the selected contact record and displayed in the FileMaker card window.

A few notes regarding this implementation:

• In the Web Viewer Setup dialog, you must select the setting “Allow JavaScript to perform FileMaker scripts”. Otherwise, the FileMaker.PerformScript()function will not work.
• The FileMaker script name which we pass as a first parameter is not case-sensitive.
• The FileMaker.PerformScript() function doesn’t wait for the FileMaker script to finish. That means the FileMaker script doesn’t return a value to the FileMaker.PerformScript() function that called it.
• The FileMaker script is executed in the current context. So if the user or script changes the layout or record while the script is running, then the FileMaker script will run in a new context. To deal with such a situation, we can pass the context information as a second parameter to the function.

The JavaScript integration in FileMaker 19 platform allows creating custom apps that can use the existing JavaScript libraries to incorporate amazing functionality easily. It enables a seamless ability to pass data back and forth between FileMaker and JavaScript.

If you are looking for support with FileMaker, or FileMaker integration, feel free to contact our us. For more details, please visit – www.metasyssoftware.com/filemaker