Page MenuHomePhabricator

New dedupe blocking issue - on hold
Closed, ResolvedPublic


In late March we started processing Silverpop information & setting mails to 'on hold' based on Silverpop data.

I'm looking at a specific instance


Where the contact is on hold as we have now processed 'Reply Mail Block' messages.

Interestingly this had NOT caused Silverpop to stop sending him mailings in the past. I though Silverpop blocked those people internally - but perhaps his history of merges explains that - since I see for a contact with less merges the same pattern isn't present.

This person has now turned up on @LeanneS's planning giving list & been imported but the on hold is blocking it from being merged. I have some pause about the fact that they would give us an email for planned giving that we can't email - does 'Reply Mail Block' block all mails from us @CCogdill_WMF ? Or only Silverpop ones? It seems odd they would give us an email address we can't email....

However, this also creates an issue where more merges will be skipped going forwards unless we add some handling - which would either be

  • merge & drop the on_hold - it will probably come back
  • merge & keep the on hold
  • double check whether on- hold is really the right way to record Reply Mail Block responses

Note that I think it would make sense if I dig into this to take a look at a couple of other conflicts that could be resolved through the script at the same time since once I'm in that space it makes sense to do related things.

@MBeat33 @Ejegg @NNichols

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 25 2019, 11:07 PM

I think we should drop the on_hold for mail block cases. Mail blocks mean
the user’s email client blocked us, either because the user marked our send
domain as undesirable, because the email client blacklisted our IP, or
because the email client requires whitelisting. It isn’t always indicative
of a user preference.

The issue of opting out is the subject of - I'm going to focus this on more narrowly on resolving merge conflicts on dedupe data - I think if we have 2 contacts with the same email & for one it is on hold we should retain the email & retain on_hold automatically & not require user intervention

I added this to the sprint as we discussed during sprint planning I would bring in the phabs that tied in well with working on T235450

Eileenmcnaughton moved this task from Backlog to Nex on the FR-Civi-Dedupe board.Wed, Oct 30, 9:26 PM

@MBeat33 you should see 'Safe Merge' automatically resolve contacts who have the same email but one is on hold now (keeping the on_hold = TRUE on the merged contact)

Eileenmcnaughton moved this task from Nex to Doing on the FR-Civi-Dedupe board.Thu, Oct 31, 3:30 AM
Eileenmcnaughton closed this task as Resolved.Tue, Nov 12, 9:13 PM