Evergreen

Bug #1124498
Comment #15

Comment 15 for bug 1124498

Revision history for this message

Josh Stompro (u-launchpad-stompro-org) wrote on 2015-01-12:

#15

Kathy, I am still working on it, here is the branch with my changes.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1124498_30day_preexpire_notice

I don't know how the sql files need to be properly formatted for upgrades and new installs. Hopefully one of the core devs can provide guidance or can just make the needed changes.

One thing that I couldn't get working was to set an event_params of recipient_email to be able to set the To: line for testing. It looks like it should work, I must be missing something that enables the params.

Here are my notes on what needs to be done to set it up after I went through it a second time. I would be happy to fix this up and add it to the official docs in the future.

How to enable the 30 Day Account Expiration Notice

Step 1 - Import the SQL to create the Hook, Event Definition, Event Params and Event Environment values.

Step 2 - Edit your /openils/conf/action_trigger_filters.json to include the following, and example is included in action_trigger_filters.json-example. This tells the action_trigger_runner to process the expire hook and filters out accounts
that are not active and deleted, as well as restricting the scope to the home_ou of the org unit.

    "expire" : {
        "context_org":"home_ou",
        "filter" :
                        { "active":"t",
                        "deleted":"f" }
        },

Step3 - Edit the event in the evergreen staff client. Under Admin -> Local Administration -> Notification/Action Triggers.
   - Edit the template if you want to change the language.
   - For testing you can replace the to: line with a specific email address and all notices will go to that address. Set it back when you are ready.
   - Change the Owning Library if you need to limit which locations send this out.
   - Enable the template when ready.
   - Processing Delay is how many days before the account expires you want to start sending out the notice. The default is -30 days.
   - Max Event Validity Delay sets a bounding date on the expiration date. The default of -29 means that only accounts that expire between -29 and -30 days from now get processed, a 24 hour period. If you want to cover a wider range of time for each run, say if you were running this weekly, then you should subtract 6 days from the current value and use -23 days. Note: An event will only be triggered once, so you won't be sending out multiple notices if your dates overlap from one run to the next. The event will only be able to repeat after the Event Repeatability delay is up.
   - Event Repeatability Delay is how long after the first notice you could send out another notice. This allows the event to fire again after an account is renewed and is about to expire again.
   - Granularity - Set a granularity to match up with how your cron jobs are setup. If you want this to be processed daily and you have a daily cron job setup, choose "daily". (Note: the ganularity settings are case sensitive. Make sure you are using the same case in your event def and in your cron jobs.)

Step 4 - Cron Jobs - Make sure your cron jobs are setup to run the action_trigger_runner.pl. If you set a "daily" granularity you need a command like
5 3 * * * . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl --osrf-config $SRF_CORE --process-hooks --granularity daily --run-pending

You can run that command manually to test it out, note: this will run all daily granularity events, not just expired.
./action_trigger_runner.pl --process-hooks --granularity daily --run-pending --verbose

You can watch /openils/var/log/osrfsys.log to see details of the action_trigger_runner.pl run. Search for "expire_date", This will show you the exact query used to find patron accounts that are expired. All datetimes are in UTC. If no notices are sent, search your user database to make sure there are any customers that expire in the time period shown.

Kathy, I am still working on it,  here is the branch with my changes.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1124498_30day_preexpire_notice

I don't know how the sql files need to be properly formatted for upgrades and new installs.  Hopefully one of the core devs can provide guidance or can just make the needed changes.

One thing that I couldn't get working was to set an event_params of recipient_email to be able to set the To: line for testing.  It looks like it should work, I must be missing something that enables the params.

Here are my notes on what needs to be done to set it up after I went through it a second time.  I would be happy to fix this up and add it to the official docs in the future.

How to enable the 30 Day Account Expiration Notice

Step 1 - Import the SQL to create the Hook, Event Definition, Event Params and Event Environment values.

Step 2 - Edit your /openils/conf/action_trigger_filters.json to include the following, and example is included in action_trigger_filters.json-example.  This tells the action_trigger_runner to process the expire hook and filters out accounts
that are not active and deleted, as well as restricting the scope to the home_ou of the org unit.

"expire" : {
        "context_org":"home_ou",
        "filter"                :
                        { "active":"t",
                        "deleted":"f" }
        },

Step3 - Edit the event in the evergreen staff client.  Under Admin -> Local Administration -> Notification/Action Triggers.
   - Edit the template if you want to change the language.
   - For testing you can replace the to: line with a specific email address and all notices will go to that address.  Set it back when you are ready.
   - Change the Owning Library if you need to limit which locations send this out.
   - Enable the template when ready.
   - Processing Delay is how many days before the account expires you want to start sending out the notice.  The default is -30 days.
   - Max Event Validity Delay sets a bounding date on the expiration date.  The default of -29 means that only accounts that expire between -29 and -30 days from now get processed, a 24 hour period.  If you want to cover a wider range of time for each run, say if you were running this weekly, then you should subtract 6 days from the current value and use -23 days.  Note: An event will only be triggered once, so you won't be sending out multiple notices if your dates overlap from one run to the next.  The event will only be able to repeat after the Event Repeatability delay is up.
   - Event Repeatability Delay is how long after the first notice you could send out another notice.  This allows the event to fire again after an account is renewed and is about to expire again.
   - Granularity - Set a granularity to match up with how your cron jobs are setup.  If you want this to be processed daily and you    have a daily cron job setup, choose "daily".  (Note: the ganularity settings are case sensitive.  Make sure you are using the same case in your event def and in your cron jobs.)

Step 4 - Cron Jobs - Make sure your cron jobs are setup to run the action_trigger_runner.pl.  If you set a "daily" granularity you need a command like
5 3 * * *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl --osrf-config $SRF_CORE --process-hooks --granularity daily --run-pending

You can watch /openils/var/log/osrfsys.log to see details of the action_trigger_runner.pl run. Search for "expire_date",  This will show you the exact query used to find patron accounts that are expired.  All datetimes are in UTC.  If no notices are sent, search your user database to make sure there are any customers that expire in the time period shown.