Page MenuHomePhabricator

Email pref centre - Solve email overwrite issue from recurring
Open, Needs TriagePublic4 Estimated Story Points

Assigned To
None
Authored By
AKanji-WMF
Dec 13 2023, 8:38 PM
Referenced Files
F57667909: image.png
Nov 1 2024, 9:03 PM
Restricted File
Oct 21 2024, 3:29 PM
Restricted File
Oct 21 2024, 3:28 PM
Restricted File
Oct 21 2024, 3:28 PM
F57630724: EmailRecordsFlowFundraiseup (1).png
Oct 21 2024, 3:22 PM
F57630709: EmailRecordsFlowPaypal.png
Oct 21 2024, 3:22 PM
F57630707: EmailRecordsFlowRegular.png
Oct 21 2024, 3:22 PM
Tokens
"Mountain of Wealth" token, awarded by AKanji-WMF.

Description

Fr-Tech is currently working on a email preferences form in Civi.

Currently if a monthly donor that came in through a processor like Paypal, GPay, Apple Pay changes their email address with this form, they are in danger of having this overwritten by whatever email address they have on file at the processor next time their recurring donation hits.

Are there ways we can solve for this? Or at least ensure the supporter is aware of what will happen?

Event Timeline

Dwisehaupt set the point value for this task to 4.Feb 5 2024, 9:37 PM

Some thoughts:

  • Messages from PayPal IPNs and audits could send email in billing_email rather than email message field
  • Queue consumer would save those as the billing email and not overwrite any 'home' email nor set billing email as primary if another email address exists.
  • Also check for the billing email in the dedupe-on-import, so we don't create extra donor records for people with a primary email different from their paypal email.

Just noting the Address source custom field now exists (& probably didn't in earlier discussion)

I'm working on this ticket but in order to understand the requirements/proposed solution, I've gone ahead to draw up a flow of how we currently manage contact emails and the proposed solution to prevent this overwrite.
Regular donations through Payment form (example CC)
{F57630733}

Donations through wallets like Paypal/Venmo
{F57630737}

Donations through Fundraiseup, we may need to turn off email modifications from either one of Email Preference center or Fundraiseup's Donor portal to avoid any confusions about which emails to set as primary.
{F57630739}

Thanks for thinking this through Dami - I find the diagrams super helpful to understand your approach!

that's weird - I came to look at the diagrams but see

image.png (330×1 px, 96 KB)

I guess my question is whether it might be worth putting them on wikitech for future us?

That's weird @Eileenmcnaughton, I'm not sure why its showing the file I deleted. I've created a section on our docs in Wikitech with these images and a description of what I had in mind.

@Damilare so the way we handle this with paypal is that we do not write the incoming email to CiviCRM at all - ie if it comes in through the Recurring Queue Consumer we do this

// Unset email & address values if the contact already has details.
// Do separate 'quick' look-ups as likely to be less lock-inducing.
$emailExists = Email::get(FALSE)
  ->addWhere('contact_id', '=', $msg['contact_id'])
  ->addSelect('email')
  ->execute()->first()['email'] ?? FALSE;
if ($emailExists) {
  // If the contact already has an email then do not attempt to update or override it
  // because this flow is only used by PayPal, which is not considered a more reliable source.
  unset($msg['email']);
}

I think that is probably the right approach - ie only save the email they specifically provide to us, unless we otherwise don't have one. If they have an email in their gpay, apple, paypal account then we shouldn't grab it unless we need it.

Note there is some real weirdness about multiple emails & our Acoustic export - it basically puts all non-primary on the master suppression list - this is perhaps being re-opened as a conversation but there is good reason not to create these extra emails if we don't need to.

Now I don't fully understand how these emails come in from the gpay/apple/paypal to understand the right fix but one approach might be

  1. at point of ingress (auditor?) add an 'email_source' to the email - we could optionally store this in a custom field in Civi like we do with Address
  2. move the handling below to the DonationMessage->normalize() function, make it depend on the email_source - ie if the email source is one of those accounts AND an email exists in Civi THEN drop the email rather than import it
Damilare subscribed.