Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
evergreen-user:action_trigger [2009/12/07 17:22] – erickson | evergreen-user:action_trigger [2012/01/04 17:41] – [Event Definitions] edoceo |
---|
== Processing Delay == | == Processing Delay == |
| |
This value defines the amount of time the system should wait after a target object becomes "relevant" before reacting on that target object. Some examples will help here: | This value defines the amount of time the system should wait after a target object becomes "relevant" before reacting on that target object. This value is stored in the database as an interval data-type, use compatible input formats. Some examples will help here: |
| |
* Overdue notices use the "checkout.due" hook. An item is technically due the second the due date hits. It is at that point the circulation becomes relevant in the context of the checkout.due hook. The goal for this type of notice, though, is to react 7 days **after** the item becomes relevant, i.e. 7 days past due (aka overdue). Note, for interval fields, you can use English text like "7 days", "3 months", etc. | * Overdue notices use the "checkout.due" hook. An item is technically due the second the due date hits. It is at that point the circulation becomes relevant in the context of the checkout.due hook. The goal for this type of notice, though, is to react 7 days **after** the item becomes relevant, i.e. 7 days past due (aka overdue). Note, for interval fields, you can use English text like "7 days", "3 months", etc. |
== Validator == | == Validator == |
| |
The validator module to use. | The validator module to use. To create a custom validator add code/modules to the ''OpenILS::Application::Trigger::Validator'' package and create an entry for this new code in the list of Validators. |
| |
== Reactor == | == Reactor == |
== Template == | == Template == |
| |
| A [[http://template-toolkit.org/|template toolkit]] input document, data are specified using the Event Environment and Event Parameters options for the event definition. This template is used, for example, by the SendEmail reactor. |
| |
| <code> |
| [% USE date %] |
| [% USE Dumper %] |
| [% SET user = target.0.usr %] |
| To: [%- user.email -%] |
| From: |
| Subject: Item Due Reminder |
| |
| Dear [% user.first_given_name %] |
| |
| [% FOR circ IN target %] |
| Title: [%- circ.target_copy.call_number.record.simple_record.title -%] |
| Barcode: [% circ.target_copy.barcode %] |
| Due: [% circ.due_date %] |
| [% END %] |
| |
| [% Dumper.dump(target) %] |
| </code> |
| |
| == Event Environment == |
| |
| Controls which data are available when processing this trigger (Validator, Reactor, Cleanup). Many trigger definitions include //usr//, //target_copy//, //pickup_lib// or //target_copy.call_number.record.simple_record//. The Event Environment values are paths to objects in the system. This data is stored in action_trigger.environment, bound to action_trigger.event_definition via event_def. |
| |
| == Event Parameters == |
| |
| This allows one to define key/value type data which becomes available during the processing of the trigger (Validator, Reactor). These options may be useful when creating custom validators for example. The Parameter Name can match ///[\w,\-\.]+///, but just ///\w+/// is more practical. The Parameter Value is eval'd on the server side, so they must be stored as valid Perl values. For strings, wrap them in quotes. This data is stored in action_trigger.event_params, also bound by event_def. |
| |