Wishlist: Action Trigger for new user creation

[Josh Stompro]

We would like the ability to send a welcome email to new customers as soon as their new accounts are created, or within a few minutes..

This has two benefits. One is that it validates the email address immediately, if there are any errors that would cause a bounce, those will get taken care of immediately. There is even a chance that the library staff will see the bounce before the customer leaves the building and can ask them to fix the email address.

Second is just a good marketing opportunity. A chance to follow up with the customer and again let them know of all the services that the library offers. Letting users know of all the services that a library provides is a challenge, so this is just one more opportunity. It would be a good chance to point the customer to all of the Library policy documents.

Another possible use could be to generate postal notices to confirm customers mailing information, or to send out welcome packets with more marketing material. I've heard of libraries that allow customers to sign up online and then mail the customer their library card, which this could also be used for.

There was a discussion on the irc channel about this idea at: http://irc.evergreen-ils.org/evergreen/2014-11-13#i_138410

One possible way to achieve this might be to add an A/T reactor tied to new rows being created in actor.usr.

Maybe there are other ways to go about it also. Based on customer created date? I'll try to become more familiar with how the reactors are defined.

I think there should be some sort of filtering possible based on user attributes like permission level, stat categories, etc. So you can choose to not email certain groups of users. Maybe that can be done in the templates?

[Josh Stompro (u-launchpad-stompro-org)]

This was really easy to setup based off of the usr.create-date value, pretty much a clone of the 30 day pre overdue notice. I don't know if this is the most efficient route to go, if we are doing a sequential scan of actor.usr every 5 minutes looking for new accounts. If that gets to be a problem we can probably add an index. If someone was running this once a day it probably isn't a big deal.

I'm working on a branch with changes needed to add this notice to a new install and upgrades.
Josh

[Josh Stompro (u-launchpad-stompro-org)]

Here is the working branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1392396_action_trigger_user_created

The setup is very similar to LP#1124498,

1. Add the hook to the action_trigger_filters.json based on the example.
2. Update database with update script.
3. Edit the event_definition and template to activate it and adjust any settings needed.
4. Add a new user to test with.
5. Process the event with the action_trigger_runner.pl set to the correct granularity.

Josh

[Josh Stompro (u-launchpad-stompro-org)]

I rebased the above branch to master and added release notes and force pushed it.
Josh

[Mike Rylander (mrylander)]

I think this is a good enhancement, but the hook key (currently "create") should be more specific. Perhaps "au.created" to follow the precedent of aur.created, as well as au.barred and au.unbarred.

Thanks, Josh!

--miker

[Josh Stompro (u-launchpad-stompro-org)]

I updated my branch to change the hook name and hook description to better match the hooks that already exist for actor.usr.
Josh

[Ben Shum (bshum)]

Assigning potential review target for 2.next as a new feature.

[Galen Charlton (gmc)]

Pushed to master for inclusion in 2.10. Thanks, Josh!

[Bill Erickson (berick)]

I'm late to the party on this one, but wanted to add some info for anyone reviewing this bug for details.

In addition to the code implemented above, there is also code in Actor.pm to create events non-passively for a hook named "au.create". The hook never existed, just the code to invoke it.

If anyone wanted to track user creation events in real time without the need for another passive event collector / config or the performance concerns raised in comment #1, creating a passive=false hook with key 'au.create' and an event def to match (similar to the one in this bug, no granularity required) it should do the trick.