EventBrite configurations allow for Hidden ticket types that in some cases don't need to be sync'ed over to Civi. Currently if there's no configuration mapping for a ticket type in EventBrite, the sync will create a record in Civi without an attendee role. We should ignore Ticket Types if there's no mapped Attendee Role.

My issue is even though I have

• set up webhooks to go to my site and ( they send to each other )
• checked my website /civicrm/api event queue and see that I am receiving the requests
• made a api key in event brite to my website as the Application url ( is this step correct? )
• set OAuth Redirect URL as blank in eventbrite
• on a live server (dream host is hosting my website ) which is accesible from the internet

I am still getting this error on my civicrm when i submit the private token of my api

Error establishing webhook configuration via Eventbrite API. Eventbrite said: 403: NOT_AUTHORIZED: This user is not able to use legacy user endpoints, please use the organization equivalent.

I set up the integration. Everything looks good but I am not receiving any data from Eventbrite.
The scheduled job logs do not show any errors.

This may just be my not understanding how this should work, but we've been utterly unable to get participants imported into Civi via the scheduled job. We've worked through issues with the API key (thanks to axelady who provided assistance in issue #23) and are seeing the event and ticket options when configuring, but... no participants. Is there a secret sauce step that's required, either in Eventbrite or Civi?

EventBrite allows partial refunds, in cases where folks might overpay or don't get group discounts. These don't update their correlative Civi record.

on the settings page /civicrm/admin/eventbrite/settings?reset=1 , I get an error that
Notice: Undefined index: webhooks in CRM_Eventbrite_Form_Settings->_confirmWebhookOnFormLoad() (line 296 of modules/civicrm_ext/com.joineryhq.eventbrite/CRM/Eventbrite/Form/Settings.php).
and it says
Error establishing webhook configuration via Eventbrite API. Eventbrite said: 403: NOT_AUTHORIZED: This user is not able to use legacy user endpoints, please use the organization equivalent.
I have added Personal Oauth token and created an organization on eventbrite.

As in title:

If the Eventbrite order is submitted without credit card payment, i.e., "pay by check", then the corresponding contribution in CiviCRM should have a status of "pending." (Currently it will have a status of "Completed".)

Hi, - I will start working on cleaned up commits and some PRs later today but my new code is here:
https://github.com/ananelson/com.joineryhq.eventbrite/

You can see an example of a customization extension here making use of the new hooks here:
https://github.com/batsimprov/batseventbrite

Adding listeners:
https://github.com/batsimprov/batseventbrite/blob/develop/batseventbrite.php#L155

Listener code:
https://github.com/batsimprov/batseventbrite/tree/develop/CRM/Batseventbrite/Listener

EventBrite includes the billing state and country in all orders even though there's no associated billing record, e.g. in pay later scenarios or attendees paid for by other attendees.

At civicrm/admin/eventbrite?reset=1, the icons and alt text are not displaying properly for the list items in the page. Under Drupal 7, CiviCRM 5.32.2 for example:

At present, if an EB order is received for a ticket type which has not been configured in CiviCRM (on an event that IS configured in CiviCRM), the integration behavior is at best unpredictable and possibly nonsensical. Consider these use cases:

Given: Ticket Type "A" is configured; Ticket Type "B" is not.

UC1. A multi-ticket order contains 1 "A" ticket and one "B" ticket. The "A" ticket should become a Partiicpant, and the Contribution will show full payment for both tickets. Should the "B" become a participant of some type? If not, will staff wonder why the "A" ticket was so expensive?

UC2. Another order is for for 1 "B" ticket. Should a contribution be created? (Probably not.) Should a participant be created? (Probably not.) Most confusing would be if a contribution is created but not the participant.

Possible solutions:

S1. Add all tickets regardless of Ticket Type. If the Ticket Type is not configured, use the event's default Participant Role.

Considering UC1, I'm not sure if there's another solution that makes sense. @josephlacey, any thoughts?

Wondering if anyone else has encountered this and already found a solution?

Optimally, the solution would iterate through the pages of potential events, or provide a search qualifier to limit the results.

I tried a few quick hack attempts to filter by active state or future dates, but could not seem to get this to filter, it just seems to return the first 50 results it gets.

Any insight appreciated. thank you

See the setup here: https://www.dropbox.com/s/2vcf0s6f36r9tbq/SETUP.docx?dl=0

In EventBrite:

1. One master event with 5 dates (sessions)
2. 6 Ticket Types. 1 for "all" events. 5 for each of the "dates"

In Civi:

1. One civi event
2. Each of the 5 dates is an event connected to the single civi event.
3. Each of the 5 dates has two ticket types - "all" and the particular date

Steps:

1. User signs up for 2 of the dates, paying $X for each day.

Actual:
User is registered for the civi event (good). The total amount the user paid was 2X, but the registration fee in Civi is recorded as just X

Expected:
Registration fee should be the total 2X (alternatively, create two registrations for the same event with fee of X).

We have a client with several years worth of events in Eventbrite. We are exploring this extension so that they can integrate Eventbrite with Civi as apart of their events workflow. We have the API key set in Civi, and it is pulling in events, however it is unclear what the metric is for the events that are listed?

The list of Eventbrite events to chose from in CiviCRM is limited to 50 events. The number of events available to choose from is undesirable, however is something that we can work around by importing past events into CiviCRM with a different method, however none of the events in the list are current. The 50 in the list are from many years ago.

This extension does not seem very viable if it only lists events from the past up to 50, and seems like a bug that could be fixed by changing the way Civi queries the Eventbrite API.

@josephlacey and I were surprised today to get this and several other similar error messages in the queue runner:

"Could not find EventbriteLink 'Event' record for order 959231762 with 'event_id': 57234242159; cannot process Order.";

Joseph had just purchased a ticket for on event (which we'll call "Testing Copy Event"), which itself was copied from the main event, which we'll call "Main Live Event". We were expecting to see three entries in the queue table from that purchase: one order.updated and two attendee.updated. We also expected that if we ran the queue runner job, those queue entries would be found and processed.

Instead we found that no queue entries were successfully processed, and several entries encountered this error or an equivalent one (i.e., with different values for orderId and eventId).

Event ID for "Testing Copy Event" is: 63000711825
Event ID for "Main Live Event" is: 57234242159

Question: Why after purchasing a ticket for "Testing Copy Event" (ID = 63000711825) are we getting errors for an order that says it's for "Main Live Event" (ID = 57234242159)?

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.

When you go to /civicrm/admin/eventbrite/settings

It just says: "The requested page could not be found."

/civicrm/admin/eventbrite
works but the table shows:

Running CiviCRM 5.32.2

Ticket Summary (by @twomice):

Per @joemcl's comment, the task at hand is to improve user experience by alerting user when a linked event has no linked ticket types, which are required for any data to be transferred.

Original starting comment from @joemcl :

Apparently a linked Ticket Type is required in the settings - which makes sense, and I had to create a ticket type in the Eventbrite event - but that wasn't obvious until I tried to figure out why attendees were not syncing. Once I selected the ticket type, then the attendees were pulled in when running the Scheduled Job manually. So, a suggestion - don't let users save a new Event in Settings unless a Ticket Type is linked :) .

Our event was set up to use eventbrite to accept payments with on "offline" option to pay by check. (More info on setup here: https://www.dropbox.com/s/2vcf0s6f36r9tbq/SETUP.docx?dl=0)

When someone registered for the event and chose this option, the contribution was created in civi as "completed".

Offline payments should be created as "Pending" so that the organization can mark it completed only when it is actually paid.

It should accurately reflect the configured Participant Role for each Ticket Type.

Buttons to Save settings should be available in the Settings form, but they are not. See this image, under Drupal 7, CiviCRM 5.32.2:

But it doesn't.

For example, if EB API provides a 'home' address for the Attendee, but CiviCRM has no active 'home' locationType.

TODO:
If the appropriate locationType is unavailable (non-existent or disabled), use the default location type.