I'm a bit confused about why it is not possible for an entity to support multiple registration fields.
I know that different registration types can support different field sets and understand the relevance of this. But what is the purpose of this functionality if only one registration field can be applied to an entity?
I have said in previous posts that it is a normal requirement for an event organiser to register different types of participants for the same event. However, even at the most basic levels, there are almost always more than one registrant type to be associated with a single event. In the case of a conference, it is necessary to register speakers and delegates; for a trade show you have exhibitors and visitors.
All need registering for the same entity and it is necessary to be able to separate the different registration types for important tasks such as invoicing and communications.
I understand that the dev team have coded the module for specific client use cases and that they have invested much time in this. Is this omission therefore completely by design or am I missing something?
Sorry if I'm being a pain, especially since I'm not a developer, but I do run events for a living and really want to help where I can.
Issue fork registration-1565504
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
dpiIm interested in helping out with this as I believe this would bring valuable flexibility to the module.
Comment #2
seanberto commentedIn short, this change would require a major rewrite of the module. We're estimating 50-100 hours of development, not including the writing of a migration path for sites using the current version of the module.
That said, we're strongly considering this enhancement and will most likely create a new branch for this work within the next month. Stay tuned.
Comment #3
mrpauldriver commentedI really appreciate the consideration being given to this request - it is an important one. Let's hope we get there eventually.
---
Edit. Removed Commerce related stuff, not relevant here.
Comment #4
john.oltman commentedComment #5
john.oltman commentedComment #6
freelockI'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?
Comment #7
john.oltman commentedI 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.
Comment #8
freelockThanks 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...