Event Action Options
"Prevent default action" (Event Actions)
Use this option to determine if your custom action should replace DayBack's default behavior.
Example Scenarios
- Default Behavior (Prevent Default Action: No)
- In scenarios where you still want DayBack's default action to occur, such as clicking an event to bring up its details, select "No" for "Prevent Default Action."
- For instance, if your "On Event Click" action is designed to record the event's start and end times, but you still want the event details to appear, choose "No."
- Custom Behavior (Prevent Default Action: Yes)
- If you want to override DayBack's default behavior completely, such as opening the event in another application instead of the DayBack popover, select "Yes."
- This will ensure DayBack stops its default action after executing your custom script.
Important Note
- Multiple Actions on the Same Trigger:
- Avoid having two actions on the same trigger (e.g., "Before Calendar Rendered") with conflicting "Prevent Default Action" settings.
- If you set one action to "Yes" and another to "No," it may lead to unexpected behavior or duplicate events.
- If you need multiple operations, combine all your code in a single action with "Prevent Default Action" set to "No."
For more examples of both settings, refer to these sample event actions.
"For events that are" (Event Actions & Custom Actions)
These checkboxes control where the action is available:
- Editable - shows up in DayBack (not in shares) and applies only to events which are not read-only
- Read Only - shows up in DayBack (not in shares) and applies only to read-only events.
- Shared - shows up in shares
Note: You can uncheck all these options to disable an action for everyone. This is handy if you're testing out your code or need to turn the action off but don't want to delete it.
For testing App Actions or Event Actions, we recommend using Draft Mode. This mode allows you to make custom changes what are only active for your user session. This mode is great for testing code changes without affecting other users. Drafts and be saved, disabled, reenabled, and then applied to production when your code changes are ready for production user.