New Feature: Generic CSV Notification Generator/Receiver
========================================================

New Action/Trigger template and sample event definitions for creating a CSV
export file for various patron actions, primarily for the purpose of creating
patron notices via external notification mechanisms.

The reference implementation for this development is the TalkingTech iTiva
product, which consumes CSV files for generating phone/text notifications and
produces CSV results files for informing the ILS of notification statuses.  
The template and send/receive scripts, however, should be generic enough to 
create CSV for any type of 3rd-party notification product.

Action/Trigger Event Definition Configuration
---------------------------------------------

  * Supported hook core types include *circ*, *ahr*, *ausp*, and *au*
  * Reactor is *ProcessTemplate*

Event Environment Requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  * Patron object with card
  * copy object
    ** circ.target_copy
    ** hold.current_copy
  * Org unit
    ** circ.circ_lib
    ** ahr.pickup_lib
    ** ausp.org_unit
    ** patron.home_ou

Not all fields are relevant to all notice types.

Required Event Parameters
~~~~~~~~~~~~~~~~~~~~~~~~~

  * notify_media (e.g. phone)
  * notify_type  (e.g. overdue)
  * notify_level (e.g. "1" -- first overdue)

The set of options for each event parameter is dependent on the 3rd-party
processing the CSV file.  

iTiva Event Parameter Options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  * notify_media
    ** V (voice)
    ** T (text)
  * notify_level
    ** 1 (1st notice)
    ** 2 (2nd notice)
    ** 3 (3rd notice)
  * notify_type 
    ** FINES 
    ** OVERDUE 
    ** PREOVERDUE 
    ** PRERESERVE 
    ** RECALL 
    ** RESERVE 
    ** RESERVECANCEL 
    ** RESERVEEXPIRE 
    ** SUSPEND

Push/Fetch Scripts
------------------

  * action_trigger_aggregator.pl collects event output from requested event 
    definitions and stitches them together into a single file, which is sent 
    via (s)FTP to the 3rd party.
  * Why don't we use the SendFile reactor directly?
    ** The final file is meant to be a collection of event-def outputs, not
       the output from a single event def
    ** The final file may be too large to reasonably store directly in a 
       single action/trigger event_output row.
  * csv_notify_fetcher.pl retrieves responses from the 3rd party and applies
    the statuses to the async_output of each notified event.