Giter VIP home page Giter VIP logo

Comments (18)

twomice avatar twomice commented on July 18, 2024

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?

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

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

from com.joineryhq.eventbrite.

twomice avatar twomice commented on July 18, 2024

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

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

I would agree with this, yes.

from com.joineryhq.eventbrite.

twomice avatar twomice commented on July 18, 2024

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?

from com.joineryhq.eventbrite.

josephlacey avatar josephlacey commented on July 18, 2024

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.

  1. 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?

from com.joineryhq.eventbrite.

twomice avatar twomice commented on July 18, 2024

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?

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

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!

from com.joineryhq.eventbrite.

twomice avatar twomice commented on July 18, 2024

@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?

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

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.

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

And yes, 50 events limit is sufficient.

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

Curious if there was any progress on this?

from com.joineryhq.eventbrite.

twomice avatar twomice commented on July 18, 2024

Sorry, no. Still on my list todo list.

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

Any updates on this?

from com.joineryhq.eventbrite.

twomice avatar twomice commented on July 18, 2024

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.

from com.joineryhq.eventbrite.

kelizoliva avatar kelizoliva commented on July 18, 2024

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.

from com.joineryhq.eventbrite.

 avatar commented on July 18, 2024

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.

from com.joineryhq.eventbrite.

twomice avatar twomice commented on July 18, 2024

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.

from com.joineryhq.eventbrite.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.