Event confirmation emails do not populate guest details when payment is confirmed by IPN (API)
This issue occurs with:
- Paid events, using an IPN payment gateway, or delayed payment
- On events that can have 'additional participants' (guests)
In this case, the event confirmation emails are missing:
- The names of additional participants
- Any custom 'participant' fields associated with the additional participants
Detailed steps to recreate:
Create custom fields assigned to the 'Participant' entity, add them to a profile
Create a free event with online registration, allowing multiple participants, and add the profile with custom fields to it, enable confirmation emails
Register for the event, with an 'additional participant'
Notice that the confirmation email contains the 'name' of the additional participant, and also the custom fields associated with their registration
Create a paid event, with the 'pay later' option (otherwise the same options as above)
Register for the event, with an 'additional participant' (pay later)
Now use the Contribution - completetransaction API call to 'complete' the payment (this is the process that would happen if the IPN was triggered).
Notice that the confirmation email does not contain the name of the participants, and any custom participant fields for the additional participants are NOT included.
Issue cause: Information from the 'form' submission is passed into the email template when it is triggered for a free event. This information is not populated when the \CRM_Event_BAO_Event::sendMail method is called from the 'completetransaction' API call. Some information is assigned in \CRM_Event_Form_Registration_Confirm::buildQuickForm and includes the $part variable, which is assigned to the template, and subsequently used in the 'online event registration' email template. The custom fields for additional participants are also assigned to the template, based on the form (https://github.com/civicrm/civicrm-core/blob/694ccbf41adc31bce4d056fcc46930ba9c2e15e5/CRM/Event/Form/Registration/Confirm.php#L311), which is also missing from the 'completetransaction' route.
Our solution: The code around this area of the system was quite spahettified, so we have solved this issue using a custom hook: https://gist.github.com/JKingsnorth/4d233df13a0f6493c44f69d81fa5f27a - although this isn't a great approach (in terms of being able to commit it back to core) - it does seem to resolve the issue.