What is the metric for Eventbrite events listed on the event integration page?

[kelizoliva]

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.

[twomice]

Thanks for reporting this. Sounds like a limitation we didn't anticipate. It should be possible to fix, though.

At some point, there's going to be a practical upper limit on the number of events we can easily pull from Eventbrite, but even then there's some way we can deal with it.

Tell me please, roughly how many events are in this Eventbrite account?

[kelizoliva]

~900-1000.

We anticipate migrating past events into CiviCRM by a batch method using an ETL, and it is reasonable that there would be limits on how many events are available to pull from Eventbrite. Like once an event has passed, it makes sense that it would stop syncing, or stop syncing at some point after the event has passed based on some metric.

[twomice]

... once an event has passed, it makes sense that it would stop syncing ...

It may be worth noting that this is already the case. The sync happens in near-real-time based on EB webhooks, so EB ticket will only be synced into CiviCRM if they are purchased (or modified) after you set up the configuration for event and ticket types within this extension.

So, as I think you're suggesting, the list of available EB events need not include any which have an end date in the past. I.e., even if there are 1000 events in the EB account, only those that have a future end date (which are the only ones people can still get tickets for) are realistic candidates for linking to a CiviCRM event.

Would you agree? Some important considerations I might be missing?

[kelizoliva]

I would agree with this, yes.

[twomice]

Been thinking about this. Currently the extension makes the naive assumption that there will be less than 50 EB events; this is inadequate for some organizations from the get-go, and for other organizations it will become inadequate as they continue using EB.

So we need to change that to something more robust, namely, all EB events with a future end date should be available for linking.

This leads to an edge case we should be careful of: Consider an EB event ending on Wednesday. On Tuesday we configure it in CiviCRM. Then on Thursday we attempt to edit that configuration (for whatever reason). The EB event will not appear as an option, because it now has an end date in the past.

To address this, we could come up with some kind of caching or more active syncing of EB events. I believe that might be more effort than it's worth.

Another way to address both the primary need and the edge case is like so:

1. As we already do, fetch the list of events from EB on every load of the "Event Configuration" form, but modify this process so that it fetches all events with a future end date (whereas it is currently limited to the first 50 events, sorted by start date).
2. When editing the event configuration, if the linked EB event is not available in the list of options, we display the "EB Event" field as read-only text, with controls (perhaps a button that reveals the option list) to allow the user to make the change, and a warning to the user (perhaps displayed when that button is clicked) that if they change the EB event link they won't be able to change it back (because that EB event is not longer one of the selectable options).

A caveat to item 1 is that it will be difficult to meet that requirement exactly. EB API doesn't allow filtering or sorting by end date (only start date and created date). There are a few options here, neither of which is ideal:

1. Fetch all events (which could be in the thousands) and use PHP to filter for only those with a future end date. This fits the requirement, but can cause high page load times (i.e., 50 per call x 1000 events @ 50 per call = 200 api calls)
2. Fetch all events with a start date no older than X days in the past (and optionally use PHP to filter for only those with a future end date). This almost fits the requirement, and is much more efficient in terms of api calls. We could also make "X" a configurable value on the settings page; defaulting to 30 days, but giving organization admins a way to extend that to as many days as they want.

Finally, one other option is to allow manual entry of an EB event ID. I fear that's clunky and error-prone and anyway isn't really needed.

@kelizoliva Does this make sense and sound workable? @josephlacey any thoughts?

[josephlacey]

I'm understanding the bug here to be primarily a sorting problem. If we limit the results to the most recently created events or the most recent start dates, probably the latter, that should solve most of the problems for folks with large EB event sets that are trying to setup syncs for their upcoming ones.

2. Fetch all events with a start date no older than X days in the past (and optionally use PHP to filter for only those with a future end date). This almost fits the requirement, and is much more efficient in terms of api calls. We could also make "X" a configurable value on the settings page; defaulting to 30 days, but giving organization admins a way to extend that to as many days as they want.

Of the two options, this one seems like the easiest to build some sensible defaults into with configurable settings of those. 30 days seems fine; retroactive data entry beyond that seems out of scope. The 50 count limit also seems. I'd offer that if an organization is syncing more than 50 simultaneous events, then this extension probably isn't the right choice for them. @twomice, did you want to use just one of these?

EB API doesn't allow filtering or sorting by end date

Can we make feature requests?

[twomice]

did you want to use just one of these?

Yes, and Option 2 is the one I was leaning to (should have been clearer about that).

30 days seems fine; retroactive data entry beyond that seems out of scope

I agree. It's conceivable someone could have an event that lasts more than 30 days, but naturally that's pretty unlikely. We can hard-code this to 30 days for now, and if there's enough interest later we can make it a configurable setting.

EB API doesn't allow filtering or sorting by end date

Can we make feature requests?

We can technically request anything in the EB API forum, so I've just now done that (https://groups.google.com/forum/#!topic/eventbrite-api/rqji2nDNWu4), but experience shows that even when they agree with the request, they're generally slow movers. Like, glaciers.

Summary: So with this, I'm proposing to implement as follows:

1. Populate the list of available EB events with the 50 latest-starting events having a start date no older than 30 days in the past (sorted alphabetically as they are currently).
2. When editing the event configuration, if the linked EB event is not available in the list of options, we display the "EB Event" field as read-only text, with button that reveals the option list to allow the user to make the change, and a warning to the user (displayed when that button is clicked) that if they change the EB event link they won't be able to change it back (because that EB event is no longer one of the selectable options).

Sound good @josephlacey ? @kelizoliva any comment on how this will affect your situation?

[kelizoliva]

Thanks for thinking this out! For my use case, the only thing I can think of where the 30 day limitation may be a problem is when an event is a series that spans a few months, but I would need to review the client's Eventbrite to verify that. Maybe 90 days?

Otherwise this all sounds good!

[twomice]

@kelizoliva An event lasting over 30 days sounds unusual to me, though it's possible of course. Could you review your client's EB data and see if that's actually the case? Also, I suppose the "50 events" limit is sufficient?

[kelizoliva]

Well, I think I'll need to address this with them, because this is happening and it is rather wild. They have an event scheduled for: Monday, March 30, 2015 at 7:00 PM - Tuesday, December 31, 2030 at 10:00 PM (PDT). It seems to be an 'online event'; in this case they are using Eventbrite to sell access to a recording of an event they had in 2015. They have another similar 'event' that is serving a similar purpose.

So let's consider this totally edge case and go ahead with events that start no further than 30 days in the past.

[kelizoliva]

And yes, 50 events limit is sufficient.

[kelizoliva]

Curious if there was any progress on this?

[twomice]

Sorry, no. Still on my list todo list.

[kelizoliva]

Any updates on this?

[twomice]

No, I'm sorry I haven't had time to address this. I'm currently booked up with time-sensitive client projects and won't be able to address this soon.

However, I would welcome a Pull Request to make this happen, if someone is able to submit that.

[kelizoliva]

We are thinking that this mostly comes down to a sorting issue; we are looking into adjusting the sorting in the extension (descending rather than ascending), and will see if that resolves things for our purposes.

[ghost]

We think we have a solution worked out. We are testing this week to see if the extension breaks with this fix, otherwise we should have a pull request up sometime next week or the week after.

[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.