Ensure correct behavior for name changes in Eventbrite

[twomice]

When an Attendee ("ticket holder") signs into Eventbrite and changes their name, what should happen? What about when the purchaser of a multi-ticket order changes the name of one of the ticket holders?

Currently the extension makes a best effort to handle this in a reasonable and cautious way, with a basic operating philosophy:

• Do no harm (don't delete data that might be used elsewhere)
• Try to match duplicates if possible, but a false negative ("not a duplicate") is better than a false positive ("is a duplicate").

The task in this issue is to document the ideal general logic involved in these name-change situations, and to ensure the extension is doing what's documented.

The extension should do as follows:

Case 1: Name change on a single-ticket order

On Monday, John Smith purchases an EB ticket in his own name. CiviCRM learns of it, and performs these actions:

• Compare the name and email address using the default unattended dedupe rule, to determine if John Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for John Smith.
• If this is a paid event, create a contribution in the amount of the ticket purchase; link* this contribution to the new participant record.
• Link the Attendee to John Smith's participant record.

On Tuesday, John Smith logs into Eventbrite and changes the name on his ticket to Jack Smith. CiviCRM learns of it and performs these actions:

• Change the status of John Smith's participant record to "Removed in EventBrite".
• Unlink the Attendee from John Smith's participant record.
• Compare the name and email address using the default unattended dedupe rule, to determine if Jack Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for Jack Smith
• If this is a paid event, find the contribution associated with John Smith's participant record, and re-associated it with Jack Smith's participant record.
• Link the Attendee to the Jack Smith's participant record.
• Log each of these changes verbosely in civicrm_eventbrite_log.

Case 2: Name change of secondary ticket-holder on a multi-ticket order

On Monday, John Smith purchases an EB ticket in his own name, and one ticket for Mary Smith, in one order. CiviCRM learns of it, and performs these actions:

• Compare the name and email address using the default unattended dedupe rule, to determine if John Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for John Smith.
• If this is a paid event, create a contribution in the amount of the ticket purchase; link this contribution to the new participant record.
• Link the Attendee to John Smith's participant record.
• Compare the name and email address using the default unattended dedupe rule, to determine if Mary Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for Mary Smith, with John Smith's participant record as the "Primary Participant."
• If this is a paid event, create a contribution in the amount of the ticket purchase; link this contribution to John Smith's participant record.
• Link the appropriate Attendees to John Smith's and Mary Smith's participant records.

On Tuesday, John Smith logs into Eventbrite and changes the name on Mary's ticket to Susan Smith. CiviCRM learns of it and performs these actions:

• Change the status of Mary Smith's participant record to "Removed in EventBrite"
• Compare the name and email address using the default unattended dedupe rule, to determine if Susan Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for Susan Smith, with John Smith's participant record as the "Primary Participant."
• Link Susan Smith's Attendee to Susan Smith's participant record.
• Log each of these changes verbosely in civicrm_eventbrite_log.

Case 3: Name change of primary ticket-holder on a multi-ticket order

On Monday, John Smith purchases an EB ticket in his own name, and one ticket for Mary Smith, in one order. CiviCRM learns of it, and performs these actions:

• Compare the name and email address using the default unattended dedupe rule, to determine if John Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for John Smith.
• If this is a paid event, create a contribution in the amount of the ticket purchase; link this contribution to the new participant record.
• Link the Attendee to John Smith's participant record.
• Compare the name and email address using the default unattended dedupe rule, to determine if Mary Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for Mary Smith, with John Smith's participant record as the "Primary Participant."
• If this is a paid event, create a contribution in the amount of the ticket purchase; link this contribution to John Smith's participant record.
• Link the appropriate Attendees to John Smith's and Mary Smith's participant records.

On Tuesday, John Smith logs into Eventbrite and changes the name on his own ticket to Jack Smith. CiviCRM learns of it and performs these actions:

• Change the status of John Smith's participant record to "Removed in EventBrite"
• Compare the name and email address using the default unattended dedupe rule, to determine if Jack Smith is an existing CiviCRM contact or not. Create a new contact if none is found by this method.
• Create a participant record for Jack Smith
• If this is a paid event, find the contribution associated with John Smith's participant record, and re-associated it with Jack Smith's participant record.
• Alter Mary Smith's participant record so that Jack Smith's participant record is the "Primary Participant"
• Link Jack Smith's Attendee to Jack Smith's participant record.
• Log each of these changes verbosely in civicrm_eventbrite_log.

* link: The extension maintains a record of links between various CiviCRM entities and Eventbrite entities. CiviCRM also maintains links between various entities. The appropriate meaning of this word should be inferred by whether or not one of two linked entities is an Eventbrite entity.

[twomice]

FYI, I've updated the README file with a note on project status. Because we don't use EB here, it's hard for me to keep this up to date, though I'm hopeful some EB user organization will be interested in sponsoring the work to get it working agian.

NOTICE of project status

This project is known to have significant issues with the current EventBrite API.

Although it worked well when first released, EB has made changes to their API, and this extension is very likely not to work completely, or perhaps in any usable way.

If you're a current EventBrite user who'd like to help sponsor the work needed get this working again, please contact us directly via https://joineryhq.com/ to discuss your needs.