- Issue created by @pfrenssen
- 🇧🇬Bulgaria pfrenssen Sofia
This is blocking ✨ Add new registrant type through the UI Active .
- 🇨🇦Canada endless_wander
Thanks for these ideas. It's an interesting way to grow to use the Registrant entity in more ways for the module. Either here or in https://www.drupal.org/project/recurring_events/issues/3477247 ✨ Add new registrant type through the UI Active , would you be able to include some use cases for Registrant types and how the increased visibility and prominence of the Registrant entities could be infused into the existing registration process?
It would be really awesome if anyone from the community of module users could share how they are using Registrant types as well, if they are.
For our site, we have a group of event programmers that would not be able to edit entity fields and manage that aspect of a site. We have a wide variety of events and many one-off custom events that require their own fields for each registrant. As an example, some events let a parent register and enter the number of children and their names in another custom field. Some other events have fields so that registrants can note their prior experience with a subject. And some other events ask for languages spoken.
Right now, we use a system by adding all of the fields to a single Registrant type (a site admin does this step) and then allowing event programmers to choose from a list of possible fields when creating their events. So site admin creates a "What is your age" field for the Registrant entity and this becomes an option in a checklist when event programmers are creating a new Event Series. The choices in this checklist control what fields end up appearing to the registrants when registering.
It's not an ideal system because we have about 15 fields where only 1 or 2 are used per event. However, I'm not sure if I would like to have a new Registrant type for each configuration of fields either as we would maybe end up with 10+ Registrant types.
In my dreams, the registration forms could work via Webform module and save registrant info as Webform submissions rather than fields on an entity. Creating and editing webforms is much easier for my client's users to grok and the Webform interface also provides a ton of useful options such as conditional fields, a wider variety of fields and the ability to craft a layout for the form. I would be curious to know what other solutions people might envision. Perhaps this is the right time to think about how handling registration forms could be improved in general? Or some kind of Webform integration could be an alternative if someone had the time to work on it.
Please let me know what you think and what your overall vision is for the use of Registrants in the module.
- 🇧🇬Bulgaria pfrenssen Sofia
Probably this is not really needed, when a new event series type is added a new registrant type is automatically created. I'm thinking now that for most regular use cases this will be sufficient. If advanced users would like to choose between multiple registrant types per event type they can add their own custom UI to handle it. This can be done by implementing regular form alter hooks.
I'm going to close this, let's focus only on use cases that are interesting for 80% of users and leave advanced cases for custom modules.