Page MenuHomePhabricator

Create opt-IN page for fundraisingEmailUnsubscribe, consume messages
Closed, ResolvedPublic4 Estimated Story Points

Description

@CCogdill_WMF will be sending emails to certain countries asking them to pro-actively opt in to our email lists. She'll need to send them a link to somewhere, and we'll want those opt-ins to end up in the new opt_in field in Civi.

We could do this with a new page in the FundraisingEmailUnsubscribe extension. It would wither send messages to a new queue with a new consumer, or send messages with a new field to the same old unsubscribe queue, whose consumer would be updated to recognize it.

Event Timeline

@CCogdill_WMF do you want to let people opt-in with a link that just has their email address, or do we need to confirm with the contact_hash or contact_id?

The only drawback with using a contact_hash or contact_id would be if the record was merged after sending the email, the target CID might not be the same as the one exported to Silverpop.

Change 451706 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[wikimedia/fundraising/SmashPig@master] Add configs for unsubscribe and opt-in queues

https://gerrit.wikimedia.org/r/451706

@Ejegg ideally, this opt-in form would work for current and non-donors, so I don't think I'd want it dependent on a CID. We could pass that data where available if it's helpful...

OK, let's keep it simple and just collect the email address on the form. When the message gets to Civi, we can mark all contacts with a matching primary email address as opted in.

Cool!

Is there a reason why we wouldn't do it for secondary, tertiary emails as
well?

If person X has primary email a@example.com, and person Y has primary email b@example.com, but a secondary email a@example.com, we would export X's record to IBM with a@example.com, and Y's record to IBM with b@example.com. Then if person X opts-in via a mail to a@example.com, we wouldn't want to opt in person Y and start sending emails to b@example.com. The issue is that opt_in is a flag on the contact record, not the email.

Okay, that makes sense (though also feels like something from a Monty
Python skit).

The situation I'm thinking of is this: Person Z is a previous donor who has
twice with 2 email addresses, c@ex.com and d@ex.com. Their records have
been merged and d@ex.com is now their secondary email. d@ex.com appears
nowhere else in our database and isn't associated with any other records.

Now Person Z comes to the opt-in page from a banner (not clicking through
on an email). They enter d@ex.com on the form. What happens then. Do they
get added as a brand new record to Civi, with no donation information
attached? Or can we use that to opt in their record, and change the
secondary to primary?

CCogdill_WMF Hmm, the old record would stay opted in, and if we merge the records, the opt_in would apply to the merged record. I don't know if the newer email address would become primary for the merged record.

So the records *would* get merged?

The reason I'm trying to solve for this is we need to "repermission" some
of the emails on the list. We need existing donors to opt back in. You say
"the old record would stay opted in" but for my purposes, it won't, because
we'll need to remove that email from our list eventually (sometime in the
next 1-2 years) if they only ever re-opt-in with the secondary email.

@CCogdill_WMF Oooh, so we would have to remove the email from Civi, not just refrain from emailing them, if they don't opt in? That's a lot higher volume data deletion than we were picturing for Eileen's 'Forgetme' work.

No no, we wouldn’t need to remove it from Civi, but it would need to be
removed from the IBM export file and from all future mailings besides TY
emails. I want to be sure I can still contact Person Z, with their full
donation history, regardless of which email they re-opt-in with.

Le ven. 10 août 2018 à 14:24, Ejegg <no-reply@phabricator.wikimedia.org> a
écrit :

Ejegg added a comment.

@CCogdill_WMF https://phabricator.wikimedia.org/p/CCogdill_WMF/ Oooh,
so we would have to remove the email from Civi, not just refrain from
emailing them, if they don't opt in? That's a lot higher volume data
deletion than we were picturing for Eileen's 'Forgetme' work.

*TASK DETAIL*
https://phabricator.wikimedia.org/T200576

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *Ejegg

*Cc: *gerritbot, Ejegg, CCogdill_WMF, Aklapper, Gaboe420, Versusxo,
Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Baloch007,
Darkminds3113, Bsandipan, Lordiis, Adik2382, Th3d3v1ls, Ramalepe, Liugev6,
Lewizho99, Maathavan, DStrine

Change 452008 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Rename iface & base class: Unsubscribe -> Subscription

https://gerrit.wikimedia.org/r/452008

Change 452015 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] WIP opt-in method

https://gerrit.wikimedia.org/r/452015

fr-tech the UI part is ready to test, the consumer is still TODO

Change 454585 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Move shared page processing logic to generic base class

https://gerrit.wikimedia.org/r/454585

Ejegg triaged this task as High priority.
Ejegg set the point value for this task to 4.

Change 455276 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Doc fixes

https://gerrit.wikimedia.org/r/455276

Change 452008 merged by jenkins-bot:
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Rename iface & base class: Unsubscribe -> Subscription

https://gerrit.wikimedia.org/r/452008

Change 452015 merged by jenkins-bot:
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Opt-in method

https://gerrit.wikimedia.org/r/452015

Change 454585 merged by jenkins-bot:
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Move shared page processing logic to generic base class

https://gerrit.wikimedia.org/r/454585

Change 455276 merged by jenkins-bot:
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Doc fixes

https://gerrit.wikimedia.org/r/455276

Change 451706 merged by jenkins-bot:
[wikimedia/fundraising/SmashPig@master] Add configs for unsubscribe and opt-in queues

https://gerrit.wikimedia.org/r/451706

Change 456517 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[wikimedia/fundraising/crm@master] WIP: Opt-in queue consumer

https://gerrit.wikimedia.org/r/456517

Change 456517 merged by jenkins-bot:
[wikimedia/fundraising/crm@master] Opt-in queue consumer

https://gerrit.wikimedia.org/r/456517

If you're testing and waiting for the opt-in to show up in civi, just know that the job to process them runs every hour on the hour.

Thanks a lot, @Ejegg!

I have some design/copy changes I will want to make. As I understand it,
payments wiki isn't currently open to any creative designers. Is that
right? Would it be possible to hand over the reigns to somebody for
modifications to this page, or do those requests need to go through you?

I guess it isn't open to any changes at all without @cwdent or @Jgreen unlocking the dbs! And when they do temporarily open it up, I think they'll want it to be edited only from devs' or pcoombe's laptops. So the best thing would be to get someone to give us the HTML and CSS they'd want changed and we can add that either via deploying code or via temporarily unlocked dbs.

Okay, that sounds reasonable enough. @Pcoombe, does that seem like enough
access to make/code creative changes to this page, as needed?

Yeah, so long as you're not expecting changes to be made instantly.

@Ejegg I spotted in my DB that after running tests associated with this ticket I have some entries in my civicrm_email table with location_type_id = NULL - might be worth checking if this happens in the wild too (or perhaps open a Phab to check?)