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

Bug #1574141 reported by Josh Stompro on 2016-04-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

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

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

tags: added: pullrequest
Galen Charlton (gmc) on 2017-05-19
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Wishlist
milestone: none → 3.0-alpha
Galen Charlton (gmc) wrote :

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.

tags: added: signedoff
Galen Charlton (gmc) wrote :

Pushed to master. Thanks, Josh!

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers