- πΊπΈUnited States freelock Seattle
I'm looking at this now -- we have a project for reserving up to 4 slots per person, for a museum. They have 2 accessible seats (wheelchair) per showing, and 25 regular seats.
I'm thinking that most of the work involved looks like changes to the HostEntity wrapper -- creating the ability to manage multiple registration fields, each tied to a registration bundle. For this particular scenario, we want to put a limit on the combined total registered on a single registration, but have distinct capacity, etc.
Anybody have a good alternative to doing this?
- πΊπΈUnited States john.oltman
I would do this using Drupal Commerce and installing Commerce Registration to bridge between Commerce and Entity Registration. Setup a Product Type in Commerce named "Museum", setup a Product Variation Type named "Showing" with fields Date and Seat Type and Registration (this last one being a Registration field of course). For each showing, create two product variation instances on the same date, one "Standard Seating" and one "Accessible Seating". Since they are separate entities they get their own Registration Settings - setup the respective capacities of 2 and 25. Users who need both types of seating will have two items in their cart. If the tickets are free, skip the Payment step in checkout. The nice thing about this is if the museums sell t-shirts etc you could add additional variation types for those other products to build out an online store. If you haven't used Commerce before it is a heavy lift but mostly config - and way less work than trying to extend Registration to support multiple registration fields per host. To extend Registration, you'd probably need to start a new branch 3.1.x.
- πΊπΈUnited States freelock Seattle
Thanks for the feedback, I'm quite familiar with Commerce.
I set up Commerce Registration as suggested, but I'm thinking this is entirely too much for this site -- they want as simple as possible of a signup -- a simple "select how many people", collect an email address and name for the registration, and send them a confirmation mail.
With Commerce Registration, it looks like you need to supply an email for each attendee, and it's a bunch more steps to first add one seating type and then the next -- and then go through a full commerce checkout to get confirmed.
I did start on this -- adding a config option to work like a "feature flag" to enable multiple registration fields on an entity. I think it would not be too hard to adjust for the scenario we are trying to build -- much of it related to the HostEntity becoming aware of multiple registration fields, and showing the unique info for each of them (we would only want to change the capacity, all other fields would be the same).
It looks like the registration table stores enough info to get the context, as long as each registration field is associated with a unique registration bundle.
That said, after talking with our client, they are going to make a decision on whether or not to move forward to this -- they might opt to keep things simple and just do a single registration type. So we're paused on this at the moment...