CiviCRM Community Forums (archive)

The issue described here:

https://issues.civicrm.org/jira/browse/CRM-5039

has been marked as fixed but unfortunately it is not.

I have just tested the 4.6alpha release by booking from two different browsers trying to book 2 different groups of 3 people on to this event.

http://dmaster.demo.civicrm.org/civicrm/event/info?reset=1&id=7

radio1 means 1 space..
radio2 means 2 spaces etc..

If you get both bookers to the confirm page with options that will oversell.. and then click confirm on both.. Only one will get the spaces.. (great so far).. the other booker will get returned to the start of the booking process but won't be able to continue as the options that are sold out are still checked but disabled (see screenshots).

A secondary issue to this is also when someone is paying offsite on a transfer type payment gateway, someone could pay faster than them and the slow person would end up paying for spaces that have sold out while they were offsite.  The way around that is to include 'pending from incomplete transaction' status as counted towards max participants.  This requires clearing pending bookings frequently for busy events.

I did actually provide the original fix as a pull request (see early comments on the issue) but it seems some of the complexity of the fix was missed when it was taken on by someone else.

The main stumbling block we had trying to incorporate the fix into civicrm properly was the part that  isn't working with this new fix.  The need to remove the sold out options from the each of the participants in the bookers session so that they can't be in the situation where the options are sold out but still selected.

The only way we found to do it was to remove the options directly from the session.. but there is almost certainly a less flaky way to do it as the session layout seemed to change depending on whether at the beginning of registration, on a 2nd/3rd participant or on the confirm stage.