Additional Filters in DayBack for FileMaker

If you're looking to add your own filters beyond the standard text, status, and resource filters that come with DayBack, you have a few options.

While it's possible to add some additional filters through URL parameters (such as for contacts and projects), a more flexible approach is to customize the scripts DayBack uses to find your events. DayBack includes subscripts specifically designed for this purpose, making it one of the easiest and most effective ways to add custom filters to your DayBack setup.

How It Works

To customize how DayBack filters your events, start by opening the script named "Apply Additional Filters - DayBack" in DayBack's FileMaker file. This script runs each time DayBack fetches your FileMaker events, allowing you to add find requests to further constrain the found set DayBack is building. That's pretty cool.

Steps to Customize Filters:

  1. Identify the Calendar to Filter:
    • Open the script and skip over the Set Variable lines at the top.
    • Locate the first If statement, which checks for a calendar named "Events." Change this to "Sample Events" or the specific name of the calendar you'd like to filter.
  2. Add Your Filter Criteria:
    • Inside the If statement, you’ll find some commented-out text for performing a "constrain found set." Use this as a template to add your custom filter criteria for the selected calendar.
  3. Handle Multiple Calendars:
    • Notice the Else If branch for a calendar named "ToDos." Change this to "ToDo List" or the name of another calendar you want to filter.
    • If you have multiple FileMaker calendars, include a branch for each one, specifying any additional filters needed.

Special Consideration for WebDirect:

If you're using WebDirect, you'll need to edit a different script: "Apply Additional Filters - SQL - DayBack." This script is necessary because, while DayBack uses Find requests to retrieve events in FileMaker client, it uses SQL to perform the "find" in WebDirect. To add additional filters in WebDirect, you'll need to modify this script by adding a WHERE clause to DayBack's SQL request.

If you have users on both WebDirect and FileMaker client, be sure to edit both scripts to ensure consistent filtering across platforms.

Hidden Filters (Pre-Filtering)

One use of these subscripts is to pre-filter the calendar, applying filters that users cannot see or change. The example code in the disabled lines within these scripts demonstrates how to implement such pre-filtering. These filters are hardcoded directly into the script by the script's author, making them invisible to users.

This method is particularly useful for situations where you want to limit the calendar to show only certain events, such as events that belong to the logged-in user, without allowing users to modify this filter.

Additional Filters

Another reason developers often use these scripts is to create additional filters that users can interact with. For example, you might want to add filters for "work type" and "procedure code" in addition to the existing status field in DayBack. To achieve this, you would create global fields for "work type" and "procedure code" and place them on the calendar layout, either in a new header, footer, or sidebar.

Next, in the "Apply Additional Filters - DayBack" script within DayBack's FileMaker file, you would check if either of these global filters has a value (indicating that the user wants to filter by "work type" or "procedure code"). If a value is present, you would enter Find mode and use the contents of these global fields as the criteria for constraining the found set.

If your DayBack FileMaker file is hosted on a server, there are a few additional steps to ensure that these filters work correctly. The “Find Events - DayBack” script runs as a Perform Script On Server (PSOS) if PSOS is available, but the server session won’t have direct access to the values in the global filters entered by the client. Fortunately, fixing this requires only two steps:

Set the filter values into the JSON object of the $parameter variable:

  • Find the line in the “Find Events - DayBack” script where, if $$Dbk_PSOSAvailable is true, the script is performed on the server. Notice that the $parameter variable is passed to this script. To include the filter values in this parameter, update the $parameter variable as follows:
JSONSetElement( $parameter ; "GlobalFilter1" ; DayBack::GlobalFilter1; JSONString )
  • You will need a separate Set Variable step for each global filter.

Retrieve these values on the server and set the global filters:

  • 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 using the value retrieved from the $parameter variable:
Set Field [DayBack::GlobalFilter1 ; JSONGetElement( $parameter ; "GlobalFilter1" )

Sorting

Currently, there is no specific sort applied to events in DayBack, though you can add one if needed. Keep in mind that in most views, events are displayed with all-day events first, followed by events in chronological order. Therefore, adding a sort will primarily affect events that are either all-day or occurring at the same time.

To implement your own sort, edit the "Find Events - DayBack" script and add the lines shown in green below. An If [] statement has been included to support different sort fields for each source, and you can add as many Else If branches as needed for your sources. Be aware that applying sorts can slow down the calendar, particularly if you choose to sort on unstored fields.

Sorting notes for Safari Browser

One interesting point to note is that Safari processes sorted data in the opposite order compared to Internet Explorer and Edge. If your users are on both Mac and Windows, you can use FileMaker's Get (SystemPlatform) function in an additional If [] statement to sort the records in opposite directions depending on the platform.