Comments (18)
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.
~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.
... 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.
I would agree with this, yes.
from com.joineryhq.eventbrite.
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:
- 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).
- 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:
- 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)
- 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.
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.
- 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.
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:
- 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).
- 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.
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.
@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.
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.
And yes, 50 events limit is sufficient.
from com.joineryhq.eventbrite.
Curious if there was any progress on this?
from com.joineryhq.eventbrite.
Sorry, no. Still on my list todo list.
from com.joineryhq.eventbrite.
Any updates on this?
from com.joineryhq.eventbrite.
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.
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.
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.
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)
- Not receiving any data from Eventbrite HOT 7
- Ensure correct behavior for name changes in Eventbrite HOT 1
- Add user alerts where no ticket type is configured HOT 5
- Civicrm Wordpress error 403 when putting in Private token api key unable to connect to eventbrite HOT 5
- 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. HOT 6
- The requested page could not be found. HOT 3
- Buttons not showing on Settings page HOT 1
- Icons and image alt text not displaying in EventBrite Integration main page HOT 1
- Major Rewrite including new EB API, Hooks for customization HOT 1
- Pay by Check creates a civi contribution in "Completed" rather than "Pending" state HOT 1
- Incorrect Total Payment HOT 1
- Participants not being imported via scheduled job HOT 4
- Dropdown event list GET from EventBrite limited to first page results (50) only. HOT 2
- If the Attendee's Ticket Type is not configured, use the event's default Participant Role HOT 1
- "Config: Event" edit form should sort events alphabetically.
- "Config: Ticket Types" page shows "Attendee" in all rows
- Ignore Billing Address creation in Civi if Street Address is blank HOT 2
- Make Ticket Type sync configuration stricter HOT 1
- Partial Refunds don't sync over to Civi HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from com.joineryhq.eventbrite.