Capture attendee's username and email in the registration

This happens on new registrations when the user only has permission to register themselves.

1. The fresh $entity object returns NULL for $entity->registrant_type($user) instead of one of the 3 valid options.
2. When there is only one option, the dropdown is hidden and the NULL #default_value is used for the rest of form processing.
3. Since it isn't one of the options, the registration is incompletely saved.

This patch works around it by only overriding #default_value when $entity->registrant_type($user) is not NULL.

For DrupalCon sites, I've updated this module and registration to the latest dev versions and went ahead and committed this patch to our BZR.

Committed.

http://drupalcode.org/project/commerce_registration.git/commitdiff/6e8e1aa

Sorry to reopen - the fix will not help with anonymous users.

The workaround should much rather be:

 if (!is_null($entity->registrant_type($user))) {
$entity->registrant_type($user) = REGISTRATION_REGISTRANT_TYPE_ANON;
}

I filed a bug with Entity Registrations: #1892512: registrant_type does not return value

@nhck - I think you may be running into another bug in registration too.

From includes/registration.forms.inc

  elseif (count($who_options) == 1) {
    $who_default = key($who_options);
  }

key() returns the key of wherever $who_option's internal array pointer happens to be. I wouldn't depend on this. Instead, reset(array_keys($who_options)) is guaranteed to return the first array key.

I've seen this cause other bugs around Commerce, #1879260: More robust query altering for line items, so I expect it could be a problem. commerce_registration should be able to assume that the #default_value from registration_form() is valid. I'm holding off on filing this since I haven't tested it.

It may be worth taking another look at commerce_registration_create_product_registration() to make sure it creates enough of an object in all cases. I think we might want to populate user_uid earlier when applicable. For our use case, only registering as myself is allowed, so we wouldn't want a stray REGISTRATION_REGISTRANT_TYPE_ANON creeping in.

I filed #1912342: key() is not reliable as a follow-up. Please re-open this, or another issue, if needed. This issue has ensured that we don't overwrite #default_value with something invalid. This module should expect registration_form() to come with a valid #defualt_value.