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.

Well, we all know how bothersome that could be! Here we are with an easy solution, read along…

Undoubtedly, navigation is an integral part of every application. It plays a pivotal role when a user requires navigating to different modules and sections.

Static navigation is rigid, which demands rework of all modules even when a single module is to be updated/added. Planning an end-to-end navigation prior to application development is the perfect solution. However, practically it is impossible to predict all modules and create a navigation way ahead of time. The second-best solution is to setup a smart extensive set of menu items for the future.

Let’s take a look at two elaborate approaches to implement a sidebar navigation!

Approach 1: Using Fixed Left Navigation

 In this approach, a button bar is added on the left-hand side of the layout in advance. Each button has calculations referring to dynamic variables as button labels, with a common script to define every button action. By default, this navigation bar is visible on all layouts.

The downside to this approach, it can work for Form views, but not for List views. Additionally, the demand for more real estate in the layout of the application is another drawback that leads us to Approach 2.

Approach 2: Hamburger Menu Using Popover

In this approach, a Hamburger menu icon is placed in the header of the layout. Clicking this will expand/collapse the popover. The popover has a button bar and it’s implementation is similar to Approach 1, with the only difference of buttons placed on the Popover. This approach works well for Form view, List view, and Table view.

Let us take a look at the Application Implementation Steps in detail.

 Step 1 – Opening Script

Create an Opening script or a Startup script to set global variable values that are used as calculation to define labels for each button segment in a Button bar.

For any new module navigation, set the global variable to the same.

Step 2 – Specify Active button

The Sidebar_Values variable defined in the Opening script will store the list of table names, i.e. main navigation module table names. It is then used to define the active button bar segment of selected module as below.

Step 3 – Main Navigation Script:

Create another script which is the main script used for navigation between modules. This script is attached to every segment of button bar, with a script parameter defined for the module to navigate.

If the user is currently on the Details view, then the application redirects to Details view of the destination module. Similarly, If the user is in List view, the application redirects to the List view of destination module.

Each layout has set icons to help navigate to Details view or List view specifically. For instance, if the user is in Details view, clicking relevant icon will help navigate to List view and vice versa.

This script checks if the user is on Details or List view and sets it to a variable. Append this variable to script parameter to get the layout where the user wants to navigate .

Step 4 – Naming convention:

Each layout requires a specific naming convention . In this case, it is <<tablename>> _<<Viewtype>>.

Here the ViewType can be DetailsView, ListView or TableView. Let’s take a look at some of these examples.

1. Contact details layout will be ‘Contacts_DetailsView’
2. Contact list layout will be ‘Contacts_ListView’
3. Contact table view layout will be ‘Contacts_TableView’

By following the Approach 2, adding a new module is matter of few simple steps and the application is as good as new.

Hope you find this article insightful. Feel free to leave a comment or post any challenges that you may have.

Our FileMaker development experience includes handling complex project management systems, e-commerce shopping sites, cruise booking systems and more.

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

Card Windows are modal to its parent window and allows the display of context-independent information from the parent window. Using the card window, users can perform actions without navigating from the parent window.

We can implement a card window using New Window or Go To Related Record script steps and selecting card as the window type. Only Close Window and Dim Parent Window options are available with card window type.

Please refer to the below screenshot

We can use the following script steps and Functions with cards in FileMaker WebDirect:

Script Steps

• New Window
• Adjust Window
• Move/Resize Window

Functions

• Get (WindowStyle)
• Get (WindowLeft)
• Get (WindowTop)

Things to bear in mind when using Card Window in WebDirect:

• The status toolbar and menu bar in the parent window are not active when a card window is open.
• Changes made in the card window will not be reflected in the parent window until the card window is closed.
• When the card window is closed, the parent window doesn’t always refresh. We can solve this problem by adding a Refresh Portalor Refresh Window script step to the close window button.
• When you are using the card window, make sure that close window button is visible in WebDirect solution. Because sometimes the close button may not be visible even if the close window option is selected. This can be handled by providing a custom close button on the layout.

Overall, the card window support in WebDirect offers an enriched user experience to Web users. We hope that this blog gives you valuable insights on card window support in WebDirect.

MetaSys has a team of experienced FileMaker developers. Please feel free to reach out should you need to support or you wish to develop FileMaker Apps. Please feel free to reach out to us at  https://development.ikf.in/metasys1/contact

Claris FileMaker 19 introduced a new script step called “Perform JavaScript in Web Viewer,” and JavaScript function, FileMaker.PerformScript(). Using this we can use the features which are readily available in JavaScript in FileMaker.

In this blog article, we will explore the “Perform JavaScript in Web Viewer” script step. Using this new feature, we are adding the jQuery datatable in our FileMaker application.

Demonstration

In our FileMaker application, we have a list of companies and their contacts. On the company list layout we display the list, and for selected companies, we display their contacts in the jQuery datatable. Using jQuery debatable, we get all the inbuilt features available with it. For e.g. We get the sort, search functionality and pagination. We don’t have to write separate code in FileMaker !

Please see the below screenshot

Let’s take a look at how we can achieve this in FileMaker application.

• Add a web viewer on the layout and give it a name.
• Embed the JavaScript function/code as a calculation result in the Web Viewer.

The screenshot above displays a JavaScript function called “showContacts” that performs the following:

• Accept one parameter from FileMaker script.
• Format the parameter in a proper format.
• Create the datatable and pass the above parameter as data to it.

In the Web Viewer, also add all the JavaScript libraries required for datatable.

Now create the script in FileMaker with “Perform JavaScript in Web Viewer” script step. This script  will call the JavaScript function that we wrote in the web viewer. In this script, create the data in JSON format, and pass this as a parameter to the JavaScript function.  Please refer to the screenshot below.

Using this new FileMaker feature, we can work on the functionalities which are readily available in JavaScript in our FileMaker application.

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