Custom App Actions

Overview

App Actions let you add our own code to the calendar in general. 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. 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 Filters Based On Calendar Selection

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

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


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.
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.

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.


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