|
Michael
|
May 8, 2015 at 12:21 pm
Hi, we have oversold an event.
You might remember that I had not fully disabled caching on all ee critical pages, which was the explanation given the last time we oversold.
Since disabling caching, we have had no oversells, until today.
The last 3 transactions for the event occurred within a couple of minutes of one another.
How can we prevent Overselling events? It’s very important that we figure this out.
We are on 4.6.19.
Thanks
|
|
Michael
|
May 8, 2015 at 12:28 pm
here is what happened. the limit was 20, we sold 27.
1 of 2 5/8/2015 12:41
2 of 2 5/8/2015 12:41
1 of 6 5/8/2015 13:27
2 of 6 5/8/2015 13:27
3 of 6 5/8/2015 13:27
4 of 6 5/8/2015 13:27
5 of 6 5/8/2015 13:27
6 of 6 5/8/2015 13:27
1 of 2 5/8/2015 13:43
2 of 2 5/8/2015 13:43
1 of 4 5/8/2015 13:48
2 of 4 5/8/2015 13:48
3 of 4 5/8/2015 13:48
4 of 4 5/8/2015 13:48
1 of 4 5/8/2015 13:51
2 of 4 5/8/2015 13:51
3 of 4 5/8/2015 13:51
4 of 4 5/8/2015 13:51
1 of 5 5/8/2015 13:53
2 of 5 5/8/2015 13:53
3 of 5 5/8/2015 13:53
4 of 5 5/8/2015 13:53
5 of 5 5/8/2015 13:53
1 of 4 5/8/2015 13:55
2 of 4 5/8/2015 13:55
3 of 4 5/8/2015 13:55
4 of 4 5/8/2015 13:55
|
|
Dean
|
May 11, 2015 at 3:51 am
Hi,
Can you provide a link to an example event please?
Can you also provide screen shots of the oversold events ticket setup? I’m particularly interested in the capacity set for the datetimes and tickets.
(It’s best to use a thirdparty image hosting system such as Droplr, Monosnap, Imgur, etc.)
|
|
Michael
|
May 11, 2015 at 4:30 am
ticket editor
I’d prefer to share links to the site privately, if possible.
thanks
|
|
Lorenzo Orlando Caum
|
May 11, 2015 at 9:08 am
Hi, your software is out of date. Could you backup and update to the current release?
https://eventespresso.com/wiki/ee4-changelog/
—
Lorenzo
|
|
Michael
|
May 11, 2015 at 9:17 am
ok, thanks.
are you aware of a bug that was fixed that caused overselling?
|
|
Tony
|
May 11, 2015 at 11:08 am
Hi Michael,
There has not been a recent bugfix for an issue for overselling.
The reason for this due to multiple sets of registrations starting at the same time(or very close together), essentially these 3 groups of registrations have made it past the checks in place for EE:
RegistrationA
1 of 4 5/8/2015 13:51
2 of 4 5/8/2015 13:51
3 of 4 5/8/2015 13:51
4 of 4 5/8/2015 13:51
RegistrationB
1 of 5 5/8/2015 13:53
2 of 5 5/8/2015 13:53
3 of 5 5/8/2015 13:53
4 of 5 5/8/2015 13:53
5 of 5 5/8/2015 13:53
RegistrationC
1 of 4 5/8/2015 13:55
2 of 4 5/8/2015 13:55
3 of 4 5/8/2015 13:55
4 of 4 5/8/2015 13:55
Just before RegistrationA started your limit was at 14.
So in the time it has taken for RegistrationA to input their details, selected a payment and made a payment (which is when the registration is switched to Approved and it then applies to the attendee limits) the other 2 registrations have started, input their details and have moved on to step 2 (selecting a payment)
At that point the registration has passed all of the limit checks, so the users pays and Approves their registration, meaning it applies to the limits.
Does that make sense?
|
|
Michael
|
May 11, 2015 at 12:02 pm
yes, I thought that might be the case.
I think another limit check should be required, upon the actual payment submission (but really before).
OR
a “hold” state that is triggered when registration is first initialized, (during which the remaining tickets would adjust accordingly) and then released on a timer if registration not yet successful, like with ticketmaster.
This is problematic for us because we are a charity that resells tickets. So we can’t, say, always hold back 10 tickets.
In many cases fewer than 10 are donated to us.
FYI, We get a very limited number of hot tickets that go very quickly, otherwise the other 99% of the time we don’t have this circumstance.
Thanks for reading.
|
|
Dean
|
May 12, 2015 at 1:12 am
Thanks Michael, I’ll certainly pass on your ideas as there looks like there is room for improvement here if we can work out the best way to achieve that.
|
