Wishlist: Email Address Alerts

[Josh Stompro]

Along the same lines as the "Address Alerts" feature, I would like to have a way to give a notification to staff and end users when an email address is entered that matches a specific regular expression.

The YAOUS for email validation will prevent staff from entering an obviously invalid email address, but it is difficult to include common typos in such a regular expression while keeping the complexity of the regex down.

Some use cases:

Prevent common typos such as "gmial.com", "hotmial.com", "hotmal.com", ".+\.coom". The feature would prevent such entries from being added and alert users that there is a problem. We see these typos on a regular basis.

Allow alerts based on the email provider. For instance, if there is an alert for "hotmail.com" that says "Please give the patron a handout about whitelisting emails from the library for Hotmail users." This wouldn't block saving the record, only alert.

Implementation ideas:
For each entry have fields for "Message", "ALERT|BLOCK","Regex","USER|STAFF|BOTH".

Message = The error or alert message displayed when regex matches.

"ALERT|BLOCK" = Is this an Alert or a Block. An Alert just shows the message, a Block keeps patron record from being saved, or email address from being added.

"Regex" = The regular expression to match.

"USER|STAFF|BOTH" = Is this alert used in the catalog, staff client or both?

Maybe this could be shoved into a YAOUS as a JSON string to keep the back end simple.

Maybe this is also more work than it is worth, maybe it is better to just search for and fix these typos when found on a regular basis via an automated script. If anyone else can think of other use cases for something like this please chime in.

Thanks
Josh

[Thomas Berezansky (tsbere)]

I am less certain about presenting anything to the user in the catalog.

As for other situations, if you know an email domain has restrictions (vtext.com converts to SMS, for example) putting a warning up would make sense. "This email address will only receive the first 120 or so characters in the message" (losing some to subject and such in this case).

If this were implemented as "send the potential address to the server, see what the server sends back" then (optionally) having the server check if there is even an A/MX record for the domain portion may be a good idea as well.

[Thomas Berezansky (tsbere)]

Oh, and another comment: Though I never got around to the Evergreen piece of it, I did start an OpenSRF service "Validator" a few years ago that I believe made it into OpenSRF master, with some basic email address checks. Using that service would allow for significant customization of some of the checks done.