Managing Undos in Custom Actions

DayBack’s custom Event Actions are powerful tools for adding additional logic to your calendar workflow. They let you add your own scripts to everyday behaviors in the calendar, like dragging or editing an event. Each action is tied to a specific “trigger” like “On Event Create” or “On Event Save. ”

The On Event Save action is one of the most important, as it can look at what changes are being made and act accordingly. However, DayBack’s undo functionality will also trigger the On Event Save action to fire. Depending on what the action is doing, developers may or may not want to have the action be triggered during an undo event. So how can developers control this behavior?

Example: Showing Custom Dialogs

In an earlier post, we looked at adding custom dialogs to the calendar’s workflow when an event was rescheduled. This is triggered in an On Event Save action by looking at the changesObject to see if the start property of an existing event has been modified.

if( event.eventID && ( changesObject.start || changesObject.end ) ) {
  //event has an eventID, so this is an existing event and not being created now
  //existing event's start property has been modified, take some action here

  ...

}

In these examples, a modal dialog box is presented to the user so they can specify who initiated the rescheduling of the event.

After the user has filled in the form, the On Event Save action completes, and the toast message displays that the action has been completed and the data has been written to the calendar source. In addition to showing the save confirmation, the toast message offers an undo option. If the user clicks on this, DayBack will make an additional edit that reverses the changes made in the original save. As originally written, this undo will also trigger the modal dialog to be displayed again because the changesObject.start property is again being modified, even though it’s just reverting the start to its original value. In this particular case, it doesn’t make sense to present the modal again to the user since the event has not really been rescheduled.

Adding the Options Object to this Action

Your actions have access to the options object; you can look to it for guidance, just like you look at the changesObject. The options object currently has just one property, isUndo, which will return true if the edit is initiated with an undo action. Developers can trap for this in the action’s code and act accordingly. For example, if we want to suppress the dialog process during an undo, we can do something like this.

if( event.eventID && !options.isUndo ( changesObject.start || changesObject.end ) ) {
  //event has an eventID, so this is an existing event and not being created now
  //Only run if this is not triggered by an undo action
  //existing event's start property has been modified, take some action here


}

Going Further: Tracking Undos in an Audit Log

You can also use the options object to explicitly track if an edit was made via an undo action. For example, if there’s an audit log associated with the event record and we see the event’s start-time change and then change right back, we can infer that this was because of an undo action, but there’s no way to tell for sure that’s what happened. However, we can use our On Event Save action to include this information in the edit.

In this example, we’re going to set up a simple On Event Save action that will detect if the edit is the result of an undo action, and if it is, it will write the current timestamp to a field on the record. Then if we’re using Salesforce, we can add the field to our field tracking history. We can then see which edits were done as part of the undo action and be sure that’s what we are observing.

We could add our new timestamp field as a custom field in DayBack, but since the changesObject supports writing to fields that aren’t mapped, we can reference that field directly in our changesObject via its API name. The benefit of referencing the field directly is that fields that are updated this way will show up at the bottom of all the edited fields and give us a clear indication of what field edits belong to the undo action. Here’s an example of this action where the field’s API name is Undo_Action__c.

//Track Undos 1.0

//Purpose:
//This action will write true to the Undo checkbox if the edit is via an undo event

//Action Type: On Event Save
//Prevent Default Action: No

//More info on custom actions here:
//https://docs.dayback.com/article/20-event-actions

if(options.isUndo){
    //this is an undo edit, write to our timestamp field for our audit log or field tracking history.
    changesObject.Undo_Action__c = moment().format();
}

Now, in the records’s field tracking history, we can see the line corresponding to the timestamp update and know that everything above this line was part of the undo action:

Conclusions

Developers will likely want to modify On Event Save actions behavior if the action is triggered by an undo. This is easily done by testing the options.isUndo property. Actions can be written to behave one way for a regular edit and differently for an undo edit, or entire actions can be set up to just run under one context or the other.