Registration quantity widget

I have been working on an implementation of multiple attendees per registration over in ✨ Allow registrations to be for multiple people -- e.g., adding guests or "plus one" Needs review 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.