Attempting to merge user with shared address fails with nasty message

[Michael Peters]

Evergreen 2.1
OpenSRF 2.0.1
PostgreSQL 9.1
Debian Squeeze

When a user attempts a patron merge, via the staff client, where one or more of the users has a shared *_address value, as a result of "cloning" at patron registration time, the merge will fail with a really nasty error (attached).

In reality, performing the actual SQL query generated by Evergreen, the fkey constraint on the shared address is apparent to someone with access to do that, but for the end user, they're left wondering why the merge failed.

In my opinion, this is a two parter:

#1 We need to **AT LEAST**tell the staff member why the merge failed, and tell them to contact whoever provides support
#2 Why not NULL out the *_address values for the subordinate user with the shared address, which will allow the merge to continue. This also will allow other users referencing those *_address values to retain their address(es).

[[e-mail] (tji)]

We recently encountered this issues twice on 2.4.

[Rogan Hamby (rogan-hamby)]

I'm still seeing this fail on 3.1 in the webclient except that no error message now. I went down a bit of a rabbit hole thinking of different scenarios in untangling users. So, I'm not putting a pull request on this:

user/rogan/lp965374_usr_merge_fails_on_shared_address

As I'm not sure it's the approach we want. It does favor simplicity though as it assumes that if the patron is being merged out and deleted any other non-deleted patron could be the new target of address could now be the FK of actor.usr_address.usr. I think it's an improvement over the current behavior but will leave it to the community to discuss further.

[Shannon Dineen (sdineen)]

For Bug Squashing week - Testing on 3.9.0 in production confirms no error message received when patron merge with linked address performed as follows. This old bug can hopefully be closed.

I created 3 user records and chose two to merge.
Lead record had no linked address, non lead record was owner of a linked address in a cloned user, the third user.

I merged the chosen two, and the merge succeeded with no error. The lead record now had 2 addresses , and the third user , untouched by merge, had greyed out address fields and the link text to the new owner record.

With LSE Patron Registration: Cloned patrons get address copy set to FALSE, addresses in cloned and saved records are linked to owning record, and address must be edited in owning record, or have the greyed out linked address removed, and a new address added, to change the address in linked user. While painful to support and train, it works.

If the LSE is set to True , the address copies over as expected, and can be edited in the third user.

I include the detail about the LSE because there is another old wish list LP bug that could probably be closed, related to the linked address behaviour that can be controlled by the LSE. See https://bugs.launchpad.net/evergreen/+bug/1245376

[Terran McCanna (tmccanna)]

Thanks for the thorough tests, Shannon! Marking this as "Won't Fix" as it's no longer an issue.