Expose open-ils.actor.invalidate.* by contact value

[Josh Stompro]

EG2.8

Hello, I would like to create a cli script for marking email and phone numbers invalid, and rather than making database changes directly I thought I would use the openSRF api that already exists. I'm looking for a faster way to deal with email bounces.

The open-ils.actor.invalidate.* functions all require the patron ID, and perform the invalidation action only on that patron.
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm#l4706

but I see that the OpenILS::Utils::BadContact->mark_users_contact_invalid function has the ability to search for all patrons with the specified email or phone and invalidate them all.
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Utils/BadContact.pm#l20

I can see that being useful, since if my script just accepts the email address to invalidate, I'm going to need to look up the patron(s) and it would be nice if I could just the functionality that someone else already created.

So I'm wondering what the best way to handle adding that ability to the OpenSRF methods is?

Add another parameter to the end of the current methods for specifying the email/phone and make the patron id optional? Would that have the potential to break current code though?

Or create a new method like open-ils.actor.invalidate.bycontact.email that accepts the email/phone instead of the patron id?

Thanks
Josh

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

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

This adds a new optional parameter for the contact value. If the patron id is left blank, and the contact value is present then it will try to invalidate the contact info for all patrons that have that contact info.

I think there also needs to be some normalization of the contact value. For email addresses we should lowercase the value and the expected value so that "<email address hidden>" matches "<email address hidden>"

For phone numbers maybe just strip out separator characters so "218-555 4564" matches "2185554564". I'm not sure what to do with trailing phone info, like extension numbers. If I'm saying that I want to invalidate "111-222-3333", should that invalidate the number if a customer has their other phone set to "111-222-3333 ext 445", and vice versa?

Thanks
Josh

[Galen Charlton (gmc)]

I've tested and signed off on the patch and added a minor code follow-up and release notes. Signoff branch is user/gmcharlt/lp1574141_signoff.

[Galen Charlton (gmc)]

Pushed to master. Thanks, Josh!