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.

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://www.metasyssoftware.com/contact

FileMaker integration is made easy due to two powerful features. Firstly, the enhanced cURL options which make it easy to interact with many systems by facilitating many common file transfer options. Secondly, the native functions to create and extract data from JSON, which makes interactions with web services easy. These features allow FileMaker to be integrated with almost any third party products that provide the APIs for communication, including Shopify.

Step One: Create a private app in the Shopify account.

• We can connect to a Shopify account by creating a private app. Shopify requires an API Key, the API password of the private app, and the store name for authentication.
• The screenshot below shows how to create a Private app and how to get the API key and API password.

• Give the appropriate API permissions required by your private app.
• As described in the Shopify documentation, Shopify authenticates private applications using the following URL format: https://{apikey}:{password}@{hostname}/admin/api/{version}/{resource}.json

Note that the ‘hostname’ refers to the store name, and ‘version’ refers to the API version in use.

Step Two: Store the required Shopify details in FileMaker

• In the FileMaker database, create the fields to store the API Key, API Password, Store Name and API Version, as shown in the screenshot below.

Step Three: Write the script

• Write a script in FileMaker which will create the product in the Shopify account using the Shopify details mentioned in Step 2. For this step, we will use the cURL and JSON features of FileMaker.
• In the script, first create the JSON array with Product details such as Product Title, Product Description, Vendor etc.
• Next, format the URL (using the URL format mentioned in Step 1) with your Shopify account details. Then use this URL in the FileMaker ‘Insert from URL’ script step and pass the JSON array using the cURL option in it.
• Please see the below screenshot for reference.

After these three steps, we are ready to publish our product from a FileMaker database to a Shopify account. If you are experiencing issues with FileMaker, or FileMaker integration, feel free to contact our FileMaker certified developers. For more details, please visit – https://www.metasyssoftware.com/filemaker

Managing daily business chores in an organized and efficient manner is no more an easy task. So it becomes imperative for organizations to invest in customized workflow management systems which can help in scaling up production. Also, since the kind of tasks involved in every organization differs, the one size fits all is now a legacy.

This article throws light on some of the most important features which should be a part of Workflow management software.

1. Intuitive dashboards:

   A good WMS should have an intuitive dashboard which will give the user an overall picture of sales, inventory, invoices etc. It should help in easy tracking of different tasks through the graphical representation of data. The WMS must help the user to navigate to different sets of data through the Dashboard.

2. Managing Roles and Access Rights:
   

   The user should be able to easily manage the roles and access rights of employees to avoid misuse of data. Some of it might be sensitive in nature and should not be accessed by everyone. So the system should allow the project managers to easily manage the roles and access rights of employees.

3. Managing and nurturing leads:

   Your WMS should act as an important sales tool and not just a contact management platform. It should help in quick access to Contacts, Communication, Invoices etc. and should help in tracking and personalizing the communication with the client.

4. Managing products:

   Managing different lineage of products/brands which are catering to different markets can be a cumbersome task. A good WMS will have all the necessary features which can help the users to manage the entire product portfolio more effortlessly! It will help you in accessing all the product details in one single platform, track all product deliveries, print, and scan all product pictures etc.

5. Project management:

   Project management is a complex task. A good WMS will have essential features like assigning different tasks to the employees, tracking time and converting project time to invoices, scheduling/ rescheduling of projects etc. The WMS should enable managing of all project deadlines within time and budget.

6. Time management:
   

   The WMS should be able to track time spent by employees on different tasks in order to make them more efficient and productive. It should divide complex tasks into different sets of actions. This will help the users to estimate the time duration of all the actions.

7. Integration with Outlook:
   

   Nowadays most of the business communication happens on Microsoft Outlook. So won’t it be great if you can access all the customer information at one single place? A workflow management software with Outlook Integration will help you to gather different business insights in one single platform.

MetaSys Software has an off the shelf customizable solution – MetaBiz which has all the above features. For downloading the trial version please visit https://www.metasyssoftware.com/meta-biz

This article is a continuation of the FileMaker OAuth 2.0 Authentication  Here we will show you how OAuth works with some sample code and how it can be used to log on to Custom FileMaker application.Steps Involved-

1. Configure FileMaker Server / Cloud
2. Create Application and configure it on provider’s account
3. Set up Groups or Accounts in FileMaker file

1. Configure FileMaker Server / Cloud

The first step to use OAuth is to enable External Authentication on FileMaker Server/Cloud.

Enabling EA on FileMaker Server: First, you need to login to Admin Console of FileMaker Server and then you can go to Database Server>>Security and in Client Authentication area select FileMaker and External Server Accounts and then enable the OAuth Providers.

Enabling EA on FileMaker Cloud: In this case, you need to login to Admin Console of FileMaker Cloud and then you can go to Configuration>> Client Authentication, and from there you can enable OAuth Identity Providers.

2. Create Application and configure it on provider’s account

Now that we have enabled OAuth Authentication next we have to Create OAuth Client ID Credentials on provider’s account.

Amazon

• Sign up at- https://login.amazon.com/manageApps
• Create OAuth Client ID Credential
• Set Allowed/Authorized Return URLs (https://FullyQualifiedDomain/oauth/redirect)
  in our case FQD: https://metasys.fmi.filemaker-cloud.com
• Copy Client ID and Client secret into FileMaker Server / Cloud
• Set up Accounts in FileMaker file

Google

• Sign up at- https://console.developers.google.com
• Create OAuth client ID Credential
• Set Allowed/Authorized Return URLs (https://FullyQualifiedDomain/oauth/redirect)
  in our case FQD: https://metasys.fmi.filemaker-cloud.com
• Copy Client ID, Client secret into FileMaker Server / Cloud
• Set up Accounts in FileMaker file

Microsoft Azure

• Sign up at- https://portal.azure.com
• Create OAuth client ID Credential
• Set Allowed/Authorized Return URLs (https://FullyQualifiedDomain/oauth/redirect)
  in our case FQD: https://metasys.fmi.filemaker-cloud.com
• Copy Client ID, Client secret and Tenant ID into FileMaker Server / Cloud
• Set up Accounts in FileMaker file

With Azure, we can also configure to log in with group

• Create Group in Azure Active Directory
• Add User to the GroupEnable Group Authentication in Application manifest (set “group membership claims”: “SecurityGroup”)