Additional Filters in DayBack for FileMaker

You may want to add your own filters on top of the text, status, and resource filters that come with DayBack.

While you can add some additional filters via URL (like for contacts and projects), you can also filter your FileMaker sources by customizing the scripts DayBack uses to find your events. DayBack even comes with subscripts written just for this purpose, making this one of the easiest and most powerful ways to add filters to DayBack.

How It Works

Open up the script "Apply Additional Filters - DayBack" in DayBack's FileMaker file. This script runs every time DayBack fetches your FileMaker events. So any find requests you include here can be used to constrain the found set DayBack is building. That's pretty cool.

Open the script and ignore the Set Variable lines at the top of the script. Find the first If statement and you'll see that's it's looking for a calendar named "Events". Switch that to "Sample Events" or to the name of the calendar you'd like to filter.

Inside that If statement, you'll see some disabled text to perform a "constrain found set". Use those as your example for any additional filter criteria you'd like to add to this calendar.

You'll see an Else If branch for a calendar named "ToDos"--switch that to "ToDo List" or to the name of any other calendar you'd like to filter. DayBack can show multiple FileMaker calendars at the same time and you'll want to include a branch here for each calendar that needs additional filters.

Are you using WebDirect?

If you're using WebDirect, you'll want to edit a slightly different script named "Apply Additional Filters - SQL - DayBack". (If you have users running WebDirect and FileMaker client, you'll edit both of these scripts.) While DayBack uses Find requests to retrieve your events in FileMaker client, it uses SQL to "find" your events in WebDirect. So if you want to constrain the find in WebDirect, you'll use this script to add an additional WHERE clause to DayBack' SQL request.

Hidden Filters (Pre-Filtering)

One application of these subscripts is to pre-filter the calendar. The example code in the disabled lines within these scripts show what such pre-filtering looks like: these are not filters users can interact with. The author of these scripts has hardcoded a filter inside the script, hiding that filter from the users.

This is one way, for example, to constrain the calendar to only show events that belong to the logged-in user.

Additional Filters

The other reason developers use these scripts is to create additional filters that users can interact with. For example, you may want to add filters for "work type" and "procedure code" to the status field already in DayBack. To do this, you'd create global fields for  "work type" and "procedure code" and add these to the calendar layout in a new header, footer, or sidebar.

Then, inside the script "Apply Additional Filters - DayBack" in DayBack's FileMaker file, you'd test to see if either of these global filters had values (to see if the users had asked to filter by "work type" or "procedure code"). If so, you'd enter find mode and set the contents of these global fields as the find criteria for your constrain.

If your DayBack FileMaker file is hosted on a server, there are a few more steps you need to do before your additional filters will function appropriately.  The “Find Events - DayBack” script runs as PSOS if PSOS is available, but your server session won’t have access to the values in the global filters entered by the client.  Fortunately, there are only two steps you need to complete in order to fix this:

  1. Set the filter values into the JSON object of the $parameter variable
  2. Retrieve these values when Find Events - DayBack runs on server, and set the global filters with these values.

To set the filter values into the $parameter variable, find the line in the “Find Events - DayBack” script where if $$Dbk_PSOSAvailable is true, we perform this same script on the server.  Notice that we pass the $parameter variable to this script.  To append the filter values to the parameter, set the $parameter variable to this: 

JSONSetElement( $parameter ; “GlobalFilter1” ; DayBack::GlobalFilter1; JSONString )

You will need a Set Variable step for each global filter.

Next, you need to retrieve these values from the parameter, and set the global filters when the script runs on server.  Navigate to the top of the “Find Events - DayBack” script.  After the step that sets the config variable, add an If statement: 

If( PatternCount( Get ( ApplicationVersion ) ; “Server”) )

Inside this If statement, set each global filter with the value retrieved from the $parameter variable: 

Set Field [DayBack::GlobalFilter1 ; JSONGetElement( $parameter ; “GlobalFilter1” )

Sorting

There is no specific sort applied currently, though you can add one. Note that on most views, events will show with all-day events first and then in chronological order, so adding a sort will really only apply to events that are either all-day or happening at the same time.

To add your own sort, edit the script "Find Events - DayBack" and add the lines shown in green below. I've added an If ( ) statement to support different sort fields for each source and you can add as may Else If branches as you have sources. Note that sorts will slow the calendar down slightly... or not so slightly if you choose to sort on unstored fields.

One interesting note is that Safari handles the sorted data in the opposite order as Internet Explorer and Edge. To account for this, if you have both Mac and Windows users, is to use FileMaker's  Get (SystemPlatform) in an additional if statement and sort the records in opposite directions, depending on the platform.