Page MenuHomePhabricator

Civi not keeping the mailing address attached to the active recurring donation after merging
Closed, ResolvedPublic

Description

Adriana (admin team) showed me that when she's deduping the recurring donor query, Civi isn't saving the mailing address attached to the active recurring donation after merging the records in the deduper interface when the most recent information appears on the right column of the deduper interface.

For example, the CIDs 4855488 and 4881649 were merged by her during our call, and the primary address you can now see for both CIDs had to be manually entered, or adjusted by her because Civi is only prioritizing the mailing addresses from the left column which happened to be the older information while it deleted the recent addresses.

Here are examples of CIDs that have not been merged, CID 17551572 and 5751719 (older donation on the left, active recurring on the right column). If we merge it, the mailing address used with the recurring donation will be substituted (deleted) by the one from the 2017 donation!

Screen Shot 2023-02-21 at 2.52.26 PM.png (270×2 px, 47 KB)

This adds a layer o complexity and extra time to complete the query since they can't flip the data on the deduper interface so they have to open the duplicate contacts manually to ensure the correct information is saved or adjusted before it gets deleted.

Possible Solutions:
1) Can Civi automatically save the information attached to the recent donation, in these cases, the recurring donations, independently of which side it appears in the deduper interface?
2) Have the data attached to the recurring donations = the most recent info, show up on the left column of the Deduper interface to ensure it gets ported into the oldest CID instead of deleting it as it is happening now. OR
3) Ability to flip data on the deduper interface, should this be the easiest thing to do.

Event Timeline

@SHust I looked a little into this & the issue is largely non-technical. When we implemented the dedupe handling the advice we got from stakeholders was to only keep the latest donor's address. What you are wanting to do differs from that - so we need to figure out who decides that behaviour

@Eileenmcnaughton Correct, but the actual problem is that Civi isn’t keeping the latest donor's address for recurring donors, as you mentioned, when they happen to be on the right column of the deduper interface!
As shared in the screenshots, the info on the right is the latest = from 2023 and is also attached to the active recurring donation, however, the deduper will merge them but only keep the address from the CIDs on the left which are from 2020 for one set and 2017 for the other. You can see more examples in any of the DR-Dedupe Recurring Donors groups.

Screen Shot 2023-02-28 at 5.15.59 PM.png (288×2 px, 43 KB)

Screen Shot 2023-02-21 at 2.52.26 PM.png (270×2 px, 47 KB)

@SHust maybe we can go over this on the screen at Civi fortnightly - I just merged the contacts you gave and

https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=5751719

now has her original primary (main) address and her original 'old 2019 address' - the deleted contact still has her home address https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=17551572 - but it is a match for the 'old 2019 address' on the kept contact so it makes sense it didn't come over

In staging example

  1. contact with the higher ID is on the left
  2. contact with the lower ID (on the right) has the more recent donation

But, this isn't enough because when I altered to that it didn't do the thing

image.png (676×1 px, 119 KB)

@SHust I replicated the issue in the following circumstances

  1. contact with the lower id has the more recent contribution
  2. both contacts have one address with the same location type
  3. there is a conflict on postal_code

I just deployed a fix for ^^ - but see how it goes & whether there are other address combos failing. The postal code conflict turned out to be required which was confusing

@Eileenmcnaughton Thank you. I’ll let you know if it fails!

XenoRyet set Final Story Points to 4.