QR Code stands for Quick Response Code which can store a large amount of content. It contains information in two dimensions, horizontal and vertical. Any type of smartphone device can scan and understand QR codes, providing businesses with a fast and direct way to guide users to go to a specific web page or link.

What if you had an inventory database providing details of the product via an API and you wish to read the contents of the QR Code for all your items? FileMaker now has the ability to read the contents of the QR Code without using any plug-in or third-party code or scanner.

QRCode Feature in FileMaker 19.5

Consider a scenario where you have QR Code images stored in your FileMaker database and you would like to retrieve the details stored in it. For instance, a books inventory application where the QR Code images of books are stored in the FileMaker application. Now to retrieve and store the details in the application, you would either need a QR Code scanner and then manually enter data or you might need a plug-in to do this. With the release of FileMaker Pro 19.5.1, your job becomes much easier. In the new version, the function ReadQRCode()will do the job for you. It is easy to use and understand too.

In the example below, we are reading a QR code, which contains the URL of a book. This URL contains a purchase link of the book. We can fetch other details of the book as well, provided it is contained in the QR code. We need a container field to store the QR code image. The user can manually insert it or scan it from the FM Go application

The ReadQRCode script, using ReadQRCode() function, will set the URL in the respective field. This script can be called on button click or as an OnObjectModify script trigger for the container field.

We have given a ‘Go’ button to navigate to the URL read by the ReadQRCode() function.

It will redirect the user to the purchase page of the book that has its details and reviews.

Note that this function is supported on macOS, iOS 15, and iPadOS 15 devices.

MetaSys Software has a sizeable group of certified FileMaker specialists with the knowledge of versions 5 through 19. For over 20 years, our clients have enjoyed working with us. Among the systems, we have deployed and managed with FileMaker are cruise booking systems, inventory management systems, and project management systems. To know more about what we offer in FileMaker, contact us now!

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