Trying to Merge a User in Collections Fails Silently

[Garry Collum]

Version 3.0.11 and current master.

In the webstaffclient trying to merge a patron that is referenced in the money.collections_tracker table (debt collect) fails silently.

This is related to bug https://bugs.launchpad.net/evergreen/+bug/914800

[Terran McCanna (tmccanna)]

In 3.2.2 I'm able to successfully merge a patron that is in collections with a patron not in collections as long as the one in collections is the lead.

However, if the patron chosen to be the lead is not the one in collections, it does indeed fail silently.

[April Durrence (april-durrence)]

Confirmed in 3.3.4. Unable to merge two accounts when the account in collections is not the lead account. In this case, the intended lead account has the up-to-date contact information and changes to name (no longer married), etc. that would be tedious to edit if the older (collection) account were made lead. Seems like this might be the case more often than not - collections account is the older one.

[Chris Sharp (chrissharp123)]

Okay, looking at this and discussing with the PINES staff. Currently, the collections tracker rows are managed only by UMS. When a patron is "put in collections" the tracker row is added and a "PATRON_IN_COLLECTIONS" standing penalty is applied to the account. At this point, if a staff member removes the standing penalty, that is not affecting the tracker table. When UMS removes a patron from collections the removal subroutine does not remove the standing penalty either.

The question we're left with is whether we should leave the removals from collections just to UMS (which makes sense since libraries are paying for the service) or just alert the user as to why the merge is failing without taking further action. Currently the MERGED_USER_IN_COLLECTIONS event is generated and logged to the browser console.

[Lindsay Stratton (lstratton)]

Having just run into this (v3.10.4) - we have libraries that are no longer working with UMS and ALSO clearing out old bills/transactions. When they remove bills/transactions and the notes (which were applied by UMS I guess?) there is no way of knowing that the record still appears in the collection tracker table.

If nothing else, it would be helpful to have a failure message indicating the collections tracker entry as the reason for the merge failure.