Table of Contents
Action Triggers give administrators the ability to set up actions for specific events. They are useful for notification events such as hold notifications.
To access the Action Triggers module, select Admin → Local Administration → Notifications / Action triggers.
You must have Local Administrator permissions to access the Action Triggers module.
You will notice four tabs on this page: Event Definitions, Hooks, Reactors and Validators.
Event Definitions is the main tab and contains the key fields when working with action triggers. These fields include:
Field | Description |
Owning Library | The shortname of the library for which the action / trigger / hook is defined. |
Name | The name of the trigger event, that links to a trigger event environment containing a set of fields that will be returned to the Validators and/or Reactors for processing. |
The name of the trigger for the trigger event. The underlying action_trigger.hook table defines the Fieldmapper class in the core_type column off of which the rest of the field definitions “hang”. | |
Enabled | Sets the given trigger as enabled or disabled. This must be set to enabled for the Action trigger to run. |
Processing Delay | Defines how long after a given trigger / hook event has occurred before the associated action (“Reactor”) will be taken. |
Processing Delay Context Field | Defines the field associated with the event on which the processing delay is calculated. For example, the processing delay context field on the hold.capture hook (which has a core_type of ahr) is capture_time. |
Processing Group Context Field | Used to batch actions based on its associated group. |
Links the action trigger to the Reactor. | |
The subroutines receive the trigger environment as an argument (see the linked Name for the environment definition) and returns either 1 if the validator is true or 0 if the validator returns false. | |
Event Repeatability Delay | Allows events to be repeated after this delay interval. |
Failure Cleanup | After an event is reacted to and if there is a failure a cleanup module can be run to clean up after the event. |
Granularity | Used to group events by how often they should be run. Options are Hourly, Daily, Weekly, Monthly, Yearly, but you may also create new values. |
Max Event Validity Delay | Allows events to have a range of time that they are valid. This value works with the Processing Delay to define a time range. |
Opt-In Settings Type | Choose which User Setting Type will decide if this event will be valid for a certain user. Use this to allow users to Opt-In or Opt-Out of certain events. |
Opt-In User Field | Set to the name of the field in the selected hook’s core type that will link the core type to the actor.usr table. |
Success Cleanup | After an event is reacted to successfully a cleanup module can be run to clean up after the event. |
Template | A Template Toolkit template that can be used to generate output. The output may or may not be used by the reactor or another external process. |