implement Twingle's double opt-in #35
Conversation
There was a problem hiding this comment.
@MarcMichalsky Thanks for the PR, I added some thoughts on the implementation.
Have you already talked to Twingle about that new API call?
| if (!empty($params['user_email'])) { | ||
| $contacts = civicrm_api3('Email', 'get', array( | ||
| 'seqential' => 1, | ||
| 'email' => $params['user_email'], | ||
| )); | ||
|
|
||
| // Get pending group memberships for user | ||
| if (!empty($contacts['values'])) { | ||
| foreach ($contacts['values'] as $contact) { | ||
| $groups = civicrm_api3('GroupContact', 'get', array( | ||
| 'sequential' => 1, | ||
| 'contact_id' => $contact['contact_id'], | ||
| 'status' => "Pending", | ||
| )); | ||
|
|
||
| // Only in newsletter groups: change group membership from pending to added | ||
| if (!empty($groups['values'])) { | ||
| foreach ($groups['values'] as $group) { | ||
| if (in_array($group['group_id'], $newsletter_groups)) { | ||
| civicrm_api3('GroupContact', 'create', array( | ||
| 'group_id' => $group['group_id'], | ||
| 'contact_id' => $contact['contact_id'], | ||
| 'status' => "Added", | ||
| $result_values['groups'][] = $group['group_id'], | ||
| )); | ||
| // Display message if group membership was confirmed correctly | ||
| $result_values['double_opt_in'][$group['group_id']] = "Subscription confirmed"; | ||
| } | ||
| } | ||
| // Display message if there is no pending group membership | ||
| } else { | ||
| $result_values['double_opt_in'][] = "Could not confirm subscription: No pending group membership"; | ||
| } | ||
| } | ||
| // Display message if email can't be found | ||
| } else { | ||
| $result_values['double_opt_in'][] = "Could not confirm subscription: Email not found"; | ||
| } | ||
| } |
There was a problem hiding this comment.
The contact should be identified using XCM, just as the submit API action does. Otherwise, this might alter group memberships for other contacts with the same e-mail address. We should also only target that one single contact identified by XCM with the same profile.
Therefore, all user_ parameters (and maybe custom_fields also) should be added to this API action.
There was a problem hiding this comment.
Considering that a Double-Opt-In confirmation always refers to an email address, I thought that matching a contact wouldn't be necessary. Especially when the contact has already been matched in the submit step. How should we keep DOI confirmations from different contacts with the same email apart, anyway?
There was a problem hiding this comment.
This is what XCM takes care of: either match a single contact or create one, according to the XCM profile configuration being used. I.e. contacts with the same e-mail address don't matter, since XCM will only return one contact ID. Since GroupContact is a thing that belongs to a contact (not an e-mail entity) - it's a crosstab with group_id and contact_id - we should really make sure we select the correct one and thus identify the previously matched contact again using XCM.
| if (empty(civicrm_api3('GroupContact', 'get', array( | ||
| 'group_id' => $group_id, | ||
| 'contact_id' => $contact_id, | ||
| ))['values'])) { | ||
| civicrm_api3('GroupContact', 'create', array( | ||
| 'group_id' => $group_id, | ||
| 'contact_id' => $contact_id, | ||
| 'status' => "Pending", | ||
| )); | ||
| $result_values['double_opt_in'][] = "Pending"; | ||
| } |
There was a problem hiding this comment.
Can we make the GroupContact.get a GroupContact.getsingle wrapped with a try and put the GroupContact.create in the catch? This would avoid "Undefined index" warnings when something goes wrong with the API call. There can only be one GroupContact record per contact_id-group_id combination.
Hey @jensschuppe, We talked about a bunch of thinks that we are missing to map all Twingle activities into our CiviCRM. We are going to contact you to talk about possible next steps. |
MarcMichalsky
changed the title
|
@MarcMichalsky I think I'd prefer not having a one-for-all update API action to keep things easy and maintainable. I can't really imagine what else would need to be updated. Also, this would always involve identifying the contact, which depends on all the Since Twingle will need to do a REST API call for confirmed Double Opt-Ins anyway, I think it doesn't matter whether it's a specific But let's see what we come up with ... |
jensschuppe
added
status:needs work
An implementation that permits the use of the Twingle Double-Opt-In procedure.
TwingleManager:
I added a new action
DoubleOptInConfirmto theTwingleDonationentity.The API call that Twingle would have to make should contain a JSON like this:
{"project_id":"tw5e8b3bd4c2589","user_email":"dummy@contact.com"}Features
fix #34