Allow the Spaces (number) field to display during checkout

Thanks @Axael! That limitation is currently by design (lines 88-92 of Plugin\Commerce\InlineForm\Registration.php) but you make a good point that the limitation may not make sense for every site, especially sites that have exposed fields during checkout. I will look into a solution for this.

Hey @john.oltman, thanks for your answer.

It looks quite obvious to me, but maybe I missed something else.
In my case, I want to sell tickets for a dinner event, and I need to ask registrants to specify the following:

- Name
- E-mail address
- How many adult meals
- How many kids meals
- How many vegetarian meals

I was thinking about using the "spaces" field for that, but there may actually be another I didn't think of (I'm new to Commerce)?

@Axael, following up - I looked into this further and limiting "Spaces" to 1 during checkout was done for a couple reasons:
* It makes validation of the maximum spaces per event more reasonable to accomplish. The idea is that people would increase the Quantity field to get more Spaces. So if I want to register for 2 spaces, I add the event item to my cart twice.
* It makes the price calculation more "fair" - if people can choose how many spaces, they can get around the "price per ticket" so to speak, so that people would pay varying amounts "per seat", which doesn't seem right.
What might makes sense is for me to remove the limitation, but add warnings in the README or maybe on the site indicating that allowing people to choose Spaces during checkout can make the price per Space variable, and is not recommended for the most common ticketing scenarios.

To answer your question - Email address is automatically collected during checkout as long as the field is included in the checkout form display and the person is doing a Guest checkout (not logged in). Email is not collected for people who are logged in, unless you allow people to register others on the site (look at the Permissions to control what options users have). But in either case, Email address is already a field associated with the Registration type, so you shouldn't need to add a new field for this.

For the Name field and how many meals - how are your charging? Is it per meal? Per person? Per "space"? You most likely want to look at using Commerce Product Attributes. Or possibly adding fields to your Registration type. It depends on what you are selling.

Thanks for your explanations, @john.oltman.

I'm selling tickets for various kinds of events, including dinners.
At the moment, I'd like to charge a certain amount for each meal sold and each meal is for 1 person (so per person, which is the same as per space, in my case).
Ideally, different meals (vegetarian, standard, child...) could have different prices.

At the moment I tried using Commerce Product variations, but if I try to register / buy 2 tickets (which means 2 persons) I can't choose a different type of meal (standard, vegetarian, child) per person.

I also tried adding a "List (text)" field to my Registration type for the same purpose which is allowing the registrant to choose a meal type for each "space" (= ticket = person), but as much as my "Allergies" text field is displaying for each registrant during checkout, the List (text) field for my meal type isn't showing up.

Setting up 3 variations, one per meal type, with a different price for each variation, should work. If I want 1 child and 1 standard, I put 2 different items in my cart. May be moot now, but if you put a field on the checkout form display for your registration type, it will be there during checkout.

Hey @john.oltman, following up on this:

I think I understand a bit better how this module works, thanks for your help.
Setting up product variations with the different type of meals indeed works nicely for my purpose. :)

However, I'm still trying to keep the checkout process as smooth and easy as possible and I can't work that out yet.

In my example above, I've got one "dinner" event with 3 meal types (veggie, standard, child - which are product variations).
I don't want customers to create an account on the website, so the checkout is always as Guest.

Let's say a user added 2 meals in his cart: one standard, one for a child.
Once the user is on the checkout page, he's presented with a "Contact information" block with an Email field.
Then there's the "Registration information" block which displays a fieldset for each space / meal, so in this case 2 fieldsets.
Inside those fieldsets, there's another Email field and the "allergies" field I added myself.

So that leaves me with 2 issues:

1. First, I'd like the user to be presented with only one Email field. I don't even need to have a different Email field per registration as most of my users will register for them and their family (including children who do not have any email address yet).

   However, removing the Email field from the registration form display for the Checkout view mode (admin/structure/registration-types/dinner/edit/form-display/checkout) induces an error (WSOD) at the end of the checkout process because these Email fields are used to send the confirmation email (which is something I need).

   I don't know how to fix this. Ideally, I'd like the confirmation email to be sent only to the email address provided in the "Contact information" checkout block, but is this possible ?

2. Second, in my case there's no way to relate the Registration information fieldsets to a specific Product variation. So as much as I need to be able to specify a name and the food allergies for each meal added to my cart, how can I know which of the fieldset relates to the child meal and which one relates to the standard meal?

I'm adding a screenshot in case my explanations aren't clear.

For item #1 - I can enhance the module to allow Email to be left off and use the order email from the Contact pane. Please open a separate Feature Request issue "Allow checkout to use Order contact email" and in the issue description, mention the WSOD that happens when the Email field is removed from the Registration checkout form display.

For item #2 - you need to enhance your Checkout Order summary to show the allergies/name per line item. You can try doing this by updating the built in "Order summary" view, and making sure your checkout flow uses the view and not the built in summary. You will need relationships from order item to registration in your listing. Should be doable. I imagine you would also want to build an admin listing for yourself for completed orders, that shows something similar. You could add this to the Order detail page on the admin side. This last part requires custom module development.

Item #1
I created a separated issue which can be found here: https://www.drupal.org/project/commerce_registration/issues/3365740 🐛 Allow anonymous checkout to use Order contact email Fixed
Thanks!

Item #2
Actually, I'm wondering if the opposite wouldn't be better: instead of enhancing the Checkout Order summary (knowing that at this point, the allergies/name for each item haven't been set yet), I should rather be able to enhance the Registration information fieldset / block to display the type of ticket/product variation which relates to each registration. Seems more logical to me, as the user can then relate the allergies/name fields that needs to be filled in to the type of ticket: in my case, the user needs to know that a name/allergies field relates to the standard meal, or the the children meal, or to the veggie meal he added to his cart. I don't know if I'm clear enough here?