Registration quantity widget

Hey Paul,

Thanks for raising this issue. This is one that I have had multiple internal battles over. I know that it is a great feature, but I also know the complexities it adds to the registration process - specifically as far as waitlisting is concerned.

I'm happy for this issue to be a discussion before it gets resolved because at this point I don't really know what to do.

Take this example: There is a family of 4 wanting to attend an event at their local library. That event only has 2 more spaces available. The family member completing the registration form enters all 4 attendee's details, but there are only 2 spots, so 2 people have to go on the waitlist. How do we determine who goes on the waitlist? Or should all 4 go on the waitlist.

Lets presume for now that 2 of those people go on the waitlist and we have some simple way to determine who they are. Someone else (not part of this family) decides they can no longer go and deletes/cancels their registration, opening up one spot. Currently we automatically promote waitlited users, one at a time, from the waitlist to the registration list. Which 1 gets promoted?

Alternatively, lets assume the entire family of 4 ends up on the waitlist. That leaves 2 spots still open for 2 single, or 1 double registration. Someone deletes/cancels their registration opening up one spot. Do we promote one of the family of four from the waitlist? Or do we have to wait until 4 spots open up? What if there are single registrants behind them on the waitlist and a single spot opens up? Should the single registrant be promoted, or should it wait until 4 open up for the family of four because they were on the waitlist first?

There are a lot of questions that made multi-registration a real pain technically and that is why I chose to go the route of one registration at a time. Which I know is not ideal for events where multiple people want to go, but its technically way simpler to deal with.

What are you thoughts? I'd love to know how you would approach these sorts of things.

In the situation where there is a group of 4 trying to book but with only 2 spaces open, an alert be raised to the person attempting the booking for 4 giving them the option to nominate 2 people to fill the current availability then the other 2 for the waitlist. That way if they are the last booking to fill the last 2 spots then by default the other 2 in the group would be the first 2 in line on the waitlist for the next available spots. Or they can be given the opportunity to risk waiting for 4 spots to become available at once and give them priority for the 4 spots. This could be solved with a backorder waitlist option if commerce is integrated with payments somehow.

Ultimately it's not the event hosts responsibility to hold open 4 spots but the attempted request should be noted on a record to give the host the opportunity to increase the amount of spaces available if they wish.

I'm still mulling this one over, this will be a pretty significant change and I don't think that I'll be getting to this any time soon. This could potentially make registration incredibly complicated and more error prone, so I want to tread carefully.

I agree it does not resolve the issue as is. But it makes it simple from a coding stand point. Having said that, I'm definitely not closing this door and I'd love if you came back with some ideas or research of other services, that could help greatly.

I have been working on an implementation of multiple attendees per registration over in #3257502: Allow registrations to be for multiple people -- e.g., adding guests or "plus one" but I now realize my approach is more closely aligned to this issue. I will move over the MR.

I made a proof of concept of storing the number of attendees on the registrant. It can be found in the MR.

How it works:

Creating an event series

There is a new option Maximum Places Per Registration (max_places) that allows event managers to control how many attendees can be included per registration. It defaults to 1, so by default the behavior will be unchanged.

Registering for an event

There is a new number field that allows the user to select how many places they want to reserve. The number is limited by the current availability, the max_places, and whether or not there is a waitlist.

For example, if the max_places are configured to 5:

• If there are enough spaces left, the user can reserve max. 5 places.
• If there are not enough spaces left, the user can reserve max. the remaining spaces.
• If there are no spaces left, the user can reserve max. 5 places on the waitlist.

I also accounted for some edge cases:

• When there is only a single place left, or max_places is set to 1, the "Places" number field is hidden, because it would not be possible to change the value and this could be confusing to users.
• User A is told there are 5 spaces left, and wants to register them. In the meantime user B snatches up some of the remaining spaces. User A will then get the message "Unfortunately, this event is now full and you must join the waitlist.". This was a bit tricky to implement because we need to somehow keep track of how many spaces that user A has seen. We cannot use form state for this because the form state is not stored before the form is submitted. I used a private tempstore with a lifetime of 10 minutes to handle this.

Managing registrants

Because there is only 1 registrant entity, we can keep an easy UX for event managers:

• Editing a multi-attendee event is now easy - just edit the registrant as before. No need to edit 5 duplicates one by one.
• Only 1 mail will ever be sent out for every action done on a registrant.
• Adding and removing guests is now also just a matter of changing the number of places.

The overview shows for each registrant how many places are reserved:

Previously when creating or editing a registrant as an event manager you had the option to either put the registrant on the waitlist, or not. I added a new option to handle this automatically depending on current availability. Then the event manager doesn't need to check if there are still enough places available:

I am not too happy with the wording "If there is no room", are there any suggestions? I also considered to simply put "Automatic".

Promoting from waitlist

It is important that the entire group of people can be promoted together. With individual registrants per attendee there is a risk that certain individuals are promoted while others stay behind on the waitlist. By having a single registrant like proposed in the MR this is handled cleanly:

The first registrant on the waitlist will be promoted as soon as there are enough places available to match the number of requested places.

Update hooks

The existing event series have the "max_places" set to 1, and existing registrants have the number of places set to 1. I reused the existing update hooks we had, but these are not fully migrating historic revisions of the event registration field data. Only the last revision is kept. I assume this was decided in the past to avoid problems if there are a large number of revisions?

Next steps:

1. Write tests.
2. Check if we can retain the simple Yes / No option for the "Add user to waitlist" dropdown, avoiding the new "If there is no room" option.

Hey @pfrenssen.
I noticed that the promoteFromWaitlist considers only one registrant to be promoted, the next one.
For this new scenario with seats, I wonder if we could consider changing this behavior.

For example: An event that has 10 seats and there are two registrants in the waitlist, the first one requesting 2 seats(Registrant A) and the second one 1 seat(Registrant B). Let's suppose that someone at an event with 5 seats is removed. Currently, only the first registrant with 2 seats is promoted(Registrant A), even with more spaces in the event for the second registrant in the waitlist (Registrant B).
Then, if another user accesses the page and tries to register the user will be registered, and the second user(Registrant B) on the waitlist is still in the waitlist.

So, what do you think if we update the promoteFromWaitlist function to iterate by the registrant while we have space on the event, instead of getting only the first one?

I did some tests in my local adding the following code in the last line of the function promoteFromWaitlist and worked.

$stillAvailable = $this->retrieveAvailability();
if ($stillAvailable > 0 && !empty($first_waitlist)) {
   $this->promoteFromWaitlist();
}

I am attaching the patch with the first proposal.
There are some scenarios for moving registrants from the waitlist that can be tricky to find a good solution.

For example, there are two users on the waitlist. The first one requested three spaces, and the second registrant requested just one. Then, one registrant is removed from the event that updates one space. What should be the behavior in this case?
Should we wait until more space is available for the first registrant?
Or should we find the first registrant on the waitlist that matches the requested spaces with the currently available spaces?

Another point is, that if there is only one space and we have users on the waitlist requesting more than one space, should we block the registration until the waitlist user is promoted?

Hey everyone, here's my suggestion to address joaopauloc.dev concerns:

1. Create a new config field in the Event series called "Waitlist promotion" with the following options:
   • Automatic promotion as soon as possible.
     Help Text: Whenever a seat becomes available, the system will go through the entire waitlist and promote the next user who requested a seat to the registrants list.
   • Automatic promotion based on requested seat count.
     Help text: When a seat becomes available, the system will check how many seats the first person in the waitlist requested. If they requested more than one seat, promotion will only occur once enough seats are available to fulfill their request.
   • Automatic promotion disabled.
     Help text: Automatic promotion will be disabled. The CMS user will be responsible for manually promoting users from the waitlist to the registrants list.
2. For the last 2 options, we should keep the registration form enabled but ensure that the users go to the waitlist, meaning that the registrants list is "locked".

I'm attaching the patch with the implementation of @carolpettirossi suggestions.

Thanks for working on this! It is a fair point that we should promote as many people from the waitlist as possible. The solution with the making the promotion configurable sounds great!

Would it be possible to commit the changes to the MR so the tests can run and the changes can be reviewed?

I will also unassign from this since I am not actively working on it any more.

Hey @pfrenssen, I'll push the changes.

I'm still seeing the old help text:

Additionally with patch #20, it doesn't seem that I can leave the capacity field blank anymore

Hey @pfrenssen, what do you think about changing the places field to be required only if the waitlist is checked?

Thanks for updating the MR @joaopauloc.dev. I think it makes sense to make the Total Number os Spaces required only if the Wailist has been enabled.

Since the options can be confusing, I updated the help text to support the CMS user.

I really like this extended help text, this is going to be super helpful for the event managers.

I noticed that the Promotion Type field is not being hidden in this particular scenario:

1. Enable the registration
2. Enable the waitlist
3. Disable the registration

I added another state condition in the promotion_type field to consider the registration checkbox.

The recent push adds an option to force all registrants to go to the waitlist. This helps Event admin to decide who they will accept to the event.

What is the status of this feature and is it expected to become part of 2.0 or 3.0 soon?