Custom App Actions

Overview

App Actions let you add our own code to the calendar as a whole. Unlike button actions and event actions, these aren't run in the context of a particular event, but rather run when app-level actions take place. For example, an app action might be some JavaScript that only loads my resources when I open DayBack, removing all the other resource folders. If you have lots and lots of resources, app actions can also create resource folders and populate them based on the results for querying your database. In the screenshot below, the resource folders and all the equipment within each folder, are pulled from the users' Equipment object in Salesforce. 

You could also run an app action when a user clicks on a calendar: and reset the status filters so only filters matching that calendar are showing. Another example: when DayBack first opens you might add an action to insert some buttons into the sidebar, buttons to open other apps, control your thermostat, almost whatever you can dream up.


Creating an app action

Creating a new action is pretty easy:

1
Log in to admin settings and you'll see "App Actions" in the left-hand sidebar towards the bottom: select that.
2
Click "Add New App Action", give it a name, and pick the event that should trigger the action.
3
Paste the code you'd like to execute where it says "JavaScript". This is obviously the tricky part--writing the action itself. Don't hesitate to get in touch and ask for help. (Note that you can also drag JS files into the code editor in DayBack if you'd rather compose your JavaScript functions in your own editor.)

Examples

Setting Calendars to Read Only Based on the Logged in User's Account Name

This action will make normally editable calendars read-only for specified users. Account names and the calendars to be read-only are defined in a configuration object at the top of the action. ReadOnlyByUser.zip

Retrieve a List of Permitted Calendars from FileMaker

This action runs a script in your FileMaker file to retrieve a list of permitted calendars. It then filters DayBack's calendars against this list and only shows those calendars named in your FileMaker script. The JS action requires a FileMaker script named "Get My Calendars" (feel free to change that name in the action code here) which returns the desired calendar names as a JSON array in a script result. See the script "Sample Resources - DayBack" for an example of how to do this. Here's the On Sources Fetched action you'll add to DayBack: CalendarNamesFromFileMaker.js

Setting Filters Based On Calendar Selection

This action selects specific resource filters based on the current source/calendar. SetSourceFilters.js.zip

Setting Filters Based On View Selection

This Salesforce action selects specific resource filters based on the current view. When on a resource view the current user and all users in their folder will be selected. On all other views, just the current user will be selected. SetFiltersByView.js.zip

Disabling or Enabling Sources/Calendars Based On DayBack User

This action will only load certain sources/calendars based on the current DayBack user. This action works on all calendar sources. Access to these calendars outside DayBack will remain unaffected. FilterCalendarList.js

Filtering Sources/Calendars Based On the Logged-In Salesforce User

This action will only load certain sources/calendars based on the current user. This action relies on getting the Salesforce user info and so only works in the Salesforce environment (ie this won't work in Basecamp or Google without some customization). FilterSalesforceSources.js

Exclude Sources/Calendars Based On the Logged-In Salesforce Profile

This action will only load certain sources/calendars based on the current user. Similar to the Filtering Sources/Calendars Based On the Logged-In Salesforce User above, the action uses the profile id and excludes the specified calendars. This action relies on getting the Salesforce user info and so only works in the Salesforce environment (ie this won't work in Basecamp or Google without some customization). ExcludeSourcesByProfile.zip

Create Resources From Users By Title

This action will dynamically load the resources in DayBack's sidebar. This is a Salesforce only action. It queries for active Salesforce Users and creates resource folders based on the User's titles and populates them with the Users' names accordingly. CreateResources-UsersByTitle.zip

Pull Resources and Statuses from a FileMaker File

Run FileMaker scripts to build lists of statuses, resources, and folders. Instructions and examples here.

Open DayBack On Today

This After Calendar Rendered action will make sure DayBack opens on the current date, rather than the last date stored in local storage. This action can be set to work on just mobile or everywhere. OpenOnToday.zip

Add a Timezone Selector

Using a Before Calendar Rendered trigger, this action adds a timezone selector to DayBack's left-hand sidebar under Settings. It also displays the current timezone to the right of the date in the calendar header. TimesoneSelector.js.zip

Go to a bookmark when DayBack loads

This is a simple one-liner that makes the calendar go to a bookmark that you specify whenever DayBack loads. This is great for when you want to have a consistent view for every user in the group whenever opening the calendar. Just add this single line to an On Sources Fetched app action, with the "Prevent default action" option left to "No", and replace  YOURBOOKMARKID with the actual id of your bookmark:

seedcodeCalendar.init('bookmarkID', 'YOURBOOKMARKID');

Select All Events for Multi-Select

This Before Calendar Rendered action adds a listener to the window that will select all events for multi-select with a certain key combination. The default key combination is Shift-A, but this can easily be configured to another combination. The action is written to not fire when the user is in a field. The command(meta) and control keys do not work as modifier keys in DayBack for FileMaker if those commands already exist as FileMaker menu items. SelectAllEvents.zip


Events that can trigger app actions

On Sources Fetched
  • Actions here happen right after DayBack retrieves the list of calendar sources.
  • Like all "fetched" statuses, this only happens when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from settings.
  • "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.
On Resources Fetched
  • Actions here happen right after DayBack retrieves the list of resources.
  • If you want to manipulate the resources that are showing, here is where you'd do it.
  • See "On Sources Fetched" above. 
On Statuses Fetched
  • Actions here happen right after DayBack retrieves the list of statuses.
  • If you want to manipulate the list of statuses that are showing, here is where you'd do it.
  • See "On Sources Fetched" above. 
Before Calendar Rendered
  • Actions will fire before DayBack draws the calendar frame, which comes before it renders the actual events.
  • They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from settings.
  • "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.
After Calendar Rendered
  • Actions will fire after DayBack has drawn the calendar frame, but before proceeding to the events.
  • They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from settings.
  • "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.
After Events Rendered
  • Actions set to this trigger will fire after DayBack has drawn all the events. It will fire even if there are no events to draw (i.e. no events match the current date range or filters).
  • They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from settings.
  • "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.
After View Changed
  • Actions set to this trigger will fire whenever a user clicks on a new view like "Day" or "Horizon".
  • They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from settings.
  • "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.
After Source Selection
  • Actions set to this trigger will fire whenever a user selects or deselects a calendar source on the "Calendars" tab of DayBack's left-hand sidebar.
  • They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from settings.
  • "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.
  • When selecting a folder, this action can fire multiple times for each item in the folder. You can look at the params.data.isLast property to determine if this is the last item in a folder being selected. This is useful if you only want your code in the action to only run once.
After Filter Selection
  • Actions set to this trigger will fire whenever a user selects or deselects a filter or clicks "clear all filters."
  • If the user has a filter applied, then actions defined here will also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from settings.
  • "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.
  • When selecting a folder or clearing filters, this action can fire multiple times for each item in the folder. You can look at the params.data.isLast property to determine if this is the last item in a folder being selected. This is useful if you only want your code in the action to only run once.


Some events pass parameters into their actions

A few events pass information into their actions in the form of parameters. You can use these parameters in your scripts to determine what caused the action to fire or learn more about the application state. To see which parameters are included, add a simple console.log to your action like this:

console.log(params.data)

The following actions include parameters: After Events Rendered, After Filter Selection, and After Source Selection.


Prevent Default Action

In most cases, "Prevent default action" would stop DayBack from continuing to start up and should almost never be used in app actions. Leave this set to "no" or ask us about what you're trying to accomplish.


Getting Locked Out

If you do accidentally turn on Prevent Default Action or have another code issue in an app action that prevents DayBack from loading, hold the shift key down while moving the mouse as DayBack loads. This will prevent the actions from firing so you can get in there and disable them.


Action Enabled For

Use this setting to restrict where an action can run. Select "App" to have it run in DayBack; select "Shares" to enable the action in shared views. Deselect both to turn the action off without deleting it =)

Still need help? Message Us Message Us