These instructions will walk you through setting up the Pre-Expiration notice. This notice is intended to be used to notify users 30 days before their accounts expire, so they have time to renew their account before it expires.
The time limits are completely configurable, so you can change the time limits to whatever makes sense for your environment, including notifying the customer after their account has expired.
If you want to have multiple notices sent out, for example, a 30 day plus a 7 day notice, you will need to setup multiple event definitions for each time limit.
There are several options you can use when specifying Action Trigger Filters. You need to complete all the setup steps before the commands in this seciton will work since they depend on the Event Definitions being setup correctly. None of the examples below use granularity settings. If you do use granularity settings you will need to make sure you include those options in your commands.
You can use the '--hooks=expire' argument to action_trigger_runner.pl. This is the simplest to try out, but one of the other methods is recommended for production since they allow you more control over filtering.
action_trigger_runner.pl --run-pending --process-hooks --hooks=expire
Using the action_trigger_filters.json file gives you the ability to filter out inactive and deleted users as well as limiting the users by the event definition org unit.
Add the following to your conf/action_trigger_filters.json. If you used a recent conf/action_trigger_filters.json.example then this should already be included.
"expire" : {
"context_org":"home_ou",
"filter" :
{ "active":"t",
"deleted":"f" }
}
You can also setup a seperate filter file just for running the pre-overdue notices. You could use this if you want to fine tune the filter for a specific org unit. For example, one org unit might decide that the only want to send out pre-expire notices to users in a specific permission group. So they could setup a seperate filter file, conf/action_trigger_filters-preexpire-org1.json that looks like the following.
{
"expire" : {
"context_org":"home_ou",
"filter" :
{ "active":"t",
"deleted":"f",
"profile":2}
}
}
This would limit to sending out pre-expired notices to those that are in permission group profile 2.
You would utilize this by specifying the custom filter file in the action_trigger_runner.pl script.
action_trigger_runner.pl --run-pending --process-hooks --custom-filters=/openils/conf/action_trigger_filters-preexpire-org1.json
Edit the event in the evergreen staff client. Under Admin → Local Administration → Notification/Action Triggers. The name of the example Event Definition is "30 Day Account Expiration Courtesy Notice". You should clone this Event Definition for production, so you always have the original to refer to. Change the name of the new clone to something unique.
-
Edit the template if you want to change the message 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 to send notices in production.
Change the Owning Library if you need to limit which patron you send this out to. This also controls who can edit and view the event definition. The Owning Library only limits the effected user records when a filter is used, so if you use the --hook method, events will be generated for all users.
Processing Delay is how many days before the account expires you want to start sending out the notice. The default is -30 days. So if you wanted to give users more or less notice you would adjust this number. This is a Postgresql interval, so the format is very flexible. "-1 week", "-1 month", "-2 weeks -1 day", " -48 hours" are all valid values.
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 add 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. A safe value would be 1/2 of your normal expiration extension time, as long as that is less than expiration extension minus processing delay.
Set a granularity to match up with how your action_trigger_runner.pl 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.)