Support multiple registration fields per host entity

Created on 7 May 2012, over 12 years ago
Updated 2 November 2023, about 1 year ago

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.

✨ Feature request
Status

Active

Version

3.0

Component

Registration Core

Created by

πŸ‡¬πŸ‡§United Kingdom mrpauldriver

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States john.oltman
  • πŸ‡ΊπŸ‡ΈUnited States john.oltman
  • πŸ‡ΊπŸ‡Έ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...

Production build 0.71.5 2024