Wishlist: Quipu eCard Integration

I have taken up the PINES code for Quipu integration and am working on making something generic that can be added to master. I'll have a collab branch to share in a few days.

I plan to strip out the KCLS and PINES specific bits and squash commits to leave the original history as coherent as possible. This will cause KCLS and PINES some pain once this goes in, but I'm not sure that can be helped.

I have rebased my work on the master branch as of 2021-11-01 and pushed it to a collab branch in the working repository: collab/dyrcona/lp1902937-quipu-integration (https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp1902937-quipu-integration).

This work is NOT ready to be integrated into Evergreen as-is. It requires a lot more work to be used for any site that would want to use it.

It is being shared in the hope that other sites might find it useful and that they can adapt it to their own particular situations.

Some things to add:

1) I have rebased the branch on master and force-pushed it.

2) I'm working on a public branch with electronic renewal capability based on additional code from PINes. (This is all still up in the air becasue CW MARS hasn't decided exactly how we want electronic renewal to work.)

3) I've been asked privately about my comment #2 above, so I think I should clarify my meaning.

This branch works. You can use it to register patrons for electronic use only card with Quipu. However, the work is incomplete because there are code changes required to do things like apply the appropriate patron type, require or not require certain id fields, register users to vote, etc.

I would really like to work on this in collaboration with PINES and other sites that use it in order to get something that is more generically useful that could be included in the Evergreen code base. The goal is to get the rough edges smoothed out with org. unit settings so that it can be used effectively without template or other modifications.

To add to point 2 in comment #3 above, PINES has a long list of account renewal requirements that may not be directly applicable to other Evergreen systems. We have a work in progress branch in the PINES repo for that, but it's not ready.

Our approach is this: When a patron logs in to My Account, it checks to see if the patron's account is eligible to renew. If so, it gives them a "Renew Now" link and pulls in a Quipu form to fill out. The Quipu side does the basic address verification (and assigns a new home library if needed) and formats the address, phone, etc. properly, then sends the info back to us and we update the database on our side.

Things that we check for eligibility:
- Account expiration date is no more than 30 days in the future
- Account is still active (for us, that means it's been used in some way in the past 3 years)
- Account is not barred
- Account has no unpaid bills
- Account has not been flagged with invalid phone or address
- Account has no blocks
- Account is in selected permission groups only (we added a checkbox to the Permission Group edit form for this)

In addition, we have a requirement that if their address changes then we'll only give them a 30-day renewal and they'll need to come into the library with their new proof of address to complete the full renewal. We use a new standing penalty to indicate that they've already been given a 30-day renewal so that they don't keep getting additional 30-day renewals rather than coming in.

AND, we also have a couple of permission groups (such as our Homebound group) that we exempt from the requirement to come in if their address changes, so they get the full renewal period and do not get the standing penalty.

For a more generic discussion of a similar feature proposal, see bug 1663295.

FYI, we rolled out our E-renew function today. Because it's so extremely specific to PINES requirements, I haven't made an attempt to make it generic, but a squashed version of what we have implemented (which is based on the prior E-application work) is available at https://git.evergreen-ils.org/?p=evergreen/pines.git;a=shortlog;h=refs/heads/quipu_renewal_CLEANED_UP

Thank you for sharing your code, Terran. However it is very difficult to work the branch that you have shared. It includes many extraneous commits related to other PINES customization and it is based on rel_3_10_0. For these reasons, I find it impossible to rebase this branch on a more recent rel_3_10 or main. I get many conflicts and I don't know what your intentions were, so I can't resolve them.

I have isolated what I think are four relevant commits for the ecard and renewal functionality, but when I try to cherry-pick these to rel_3_10 or to main, I still get conflicts that I am unable to resolve.

If you could provide another branch with just these four commits on top of a recent rel_3_10 or main, it would be extremely helpful:

b65d8f18ba425566e9192fc2feb549e111dbc08f
956125f4004628539f43bf87fdaa5649fb8bd61d
d74979198daea9fc39993ec7d5b4aaa987faccc7
5acbe9ba703015b7ddddd158bc93269fb82b6911
e2a266114902c32d583ab13d4d54cdc56a45581e

Thanks,
Jason Stephenson

I am working on a more up to date branch based on Terran's renewal code. There is a lot of work left to do to make it more generic, but we're staring testing with Quipu soon. I will wait for the outcome of the testing before linking the new branch to this ticket as there will likely be more changes.

I am also working on a document of changes that are required to make this code generic enough to be used by any Evergreen site. The renewal code introduced even more hard coded assumptions.

FYI, I made a new branch with the current PINES code (rebased to 3.12 with some more fixes added that were made after comment 6) separated out from all of our other local customizations here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/pines_quipu_stuff

As Jason said, it would need a lot of work to make it generic.

PaILS is getting ready to implement this product and is interested in exploring/funding development to move (at least parts of) this integration into evergreen-main.

Westchester is currently investigating Quipu eCard and eRenew, particularly as it also integrates with Aspen.