Adding user uid and making email optional

A design decision has been made to make the registrant identifiable by email. Would you prefer people to be uniquely identified by Drupal user? You still need an email to be a Drupal user.

Do you have any recommendations?

In response to #1, the Signup module uses an automatically incrementing "Signup ID" integer as the unique identifier. A potential drawbacks to using email address as the unique identifier for a signup is that it duplicates information already stored in the user object.

Is there a specific benefit to storing the email address by default in both places?

After further investigation, I see that we do store a unique registration_id. It seems like the motivation (similar to the Signup module) is to make anonymous registrations possible where no user account exists.

If that's accurate, perhaps the mail field could be hidden for authenticated users, and we could by default ship with a registration_uid field (to distinguish the registrant from the person who created the registration)?

by default ship with a registration_uid field (to distinguish the registrant from the person who created the registration)?

+1

I'd also prefer some other form of a unique ID other than an email. If this is being designed for wide and varied use applications the email is not the most accessible in certain demographics. Also many people prefer not to provide an email.

Its a broad idea, but this is what I am thinking so far:

Built in functionality of Registration should be: username autocomplete field on registration form, associating a registration with a Drupal user.

• Add user id field to registrations table.
  (Remember: author != registered user). Defaults to NULL.
• Change mail field properties:
  not null to false, defaults to NULL.

Split out anonymous functionality to submodule. Functionality would include:

• Adding email field to registration form, allowing user to choose not to use Drupal user.
  This is current built-in functionality of Registration.
• Handles un-register functionality
  creation of unsubscribe hashes for emails.
  Add a registration <-> hash pair table.

I think separation of anonymous functionality would be ideal due to unsubscribing issues (see #1308908: Registerd user cancels a registration) which adds additional overhead for those who just want to use Drupal users.

I think long term we need a separate registrants table, where we'd keep email for anonymous and uid for authenticated registrants. Reason being so that a single user could register multiple registrants. We would also need this to handle registration verifications (especially important for anon) and allowing users to unsubscribe themselves. The hash @dpi mentions could be stored there. Thoughts?

@levelos I dont understand why a single user couldnt register multiple registrants, by using current table structure + 1 column.

Registrations should be one table!

Fields:

* registration_id
* type
* entity_id
* entity_type
* mail (only fill for anon)
* uid (only fill for Drupal user, this is the only field that should be added)
* count
* author_uid creator of registration
* created
* updated

Add one extra table for anonymous:

Containing only two fields:

* registration_id
* hash (for unsubscribing)

I dont follow what the logic is to: splitting {registrations} into two tables (one for Drupal users, one for anonymous), and adding hash to the anonymous table.

I'm not suggesting having a separate table for anonymous vs auth registrations. Use case:

User X from company Y wants to register all his colleagues. She completes the registration process providing information on 5 people total, including herself. There is a single registration, created by X, with 5 registrants tied to it. Those individual registrants need to be tied back to a single registration, manage their status, etc. Even more relevant if it's a paid registration and you need to tie an order to each of the registrants through their parent registration. I'm open to alternatives, this jumps out as making sense to me.

I also want to clarify our initial reason for leaving the user out of the registration. Since some type of user field could be added to registration bundle (E.g., entity reference, relation, or references), we didn't want to make assumptions about how users would be related to a registration. Further, if you allow multiple values on the user field, that'd be one way a single person can register multiple users. We also explored using field_collection as a way to allow a single person to enter more than one piece of information for a group of registrants. E.g., first name, last name, etc.

Finally, I want to mention that another reason that email is required is to simplify the broadcast and reminder functionality. I realize that we could get to an email from the user object, but not if we don't know how users are related to a registration.

Ok, I misinterpreted what you were saying.

Why have the email field in the registrations table at all then? Why not just have it in the associated 'people' table. If you need to blast an email to the author, you would use author_uid-> user object -> email.

Some thoughts on what I am interpreting what you are saying:

Existing {registration} table thought of as "slots".

• registration_id (primary, auto increment)
• type
• entity_id
• entity_type
• count
• author_uid
• created
• updated

{registrations people}

• id (primary, auto increment)
• registration_id (parent relationship)
• mail (default: NULL)
• uid (default: NULL)
• hash here, or in separate table.

This seems overly complicated. I'm sure adding this "people" table would complicate things a lot more than it needs to be, especially when constructing views.

Hi, I am excited about Entity Registration with Commerce Registration. I have a site that is nearly ready except for the registration component. When I found your module I was hopeful that it would be the answer.

The site I am working on is a non-profit that has nature day camps. Often parents sign up siblings for the same camp. This is where the email becomes a problem, because it is the children who are the multiple registrants (no email) and the one registering them, the parent, has one email.

I don't know if changing the email requirement is something that is being worked on or not. I wanted to add my case scenario so you know that using something other than an email would solve an important issue.

Also, I am wondering if a parent signs up the same child for multiple camps, which is often the case, will the email be accepted for each camp even though the email is the same?

Which leads me to the next thing. Is there a way to have the parent register for multiple programs (products), by adding them to the Commerce cart, but only enter the registrant (child's) information only once?

Thank you.

There is a single registration, created by X, with 5 registrants tied to it. Those individual registrants need to be tied back to a single registration, manage their status, etc. Even more relevant if it's a paid registration and you need to tie an order to each of the registrants through their parent registration. I'm open to alternatives, this jumps out as making sense to me.

If you need to have users associate event registration with an order, why not selectively use the order functionality provided by Drupal Commerce? My sense is that order tracking is out of scope from Entity Registration. By using Commerce, Entity Registrations can benefit from any additional features related to order viewing/tracking/reports rather than building them again specific to ER.

Finally, I want to mention that another reason that email is required is to simplify the broadcast and reminder functionality. I realize that we could get to an email from the user object, but not if we don't know how users are related to a registration

The Signup module supports anonymous and authenticated signups to a single event and manages to store them in a single table by referring either to a single UID or an optional anon_mail column, without duplicating the storage of information from the user object.

Being able to simply create a listing of attendees without additional joins (eg with Views) is another compelling reason to store this information in a single table.

My question is: why even separate the registrations from registrants? It's going to cause a nightmare with fields. Where do you attach fields now? The registrants now have to become a fieldable entity, and thus still need their own registration ID, otherwise you're entering registration bundle fields for a single parent registration and assuming each registrant for that registration is to use those field values.

In trying to have a parent-child relationship in terms of registration/registrants, why? It somewhat duplicates something like Drupal Commerce with the parent being the order that ties the registrants together. If you don't have Drupal Commerce (thus no order ID; think free events), just create a key that links registrations together, such as the author and created time in a separate hash. You could still add the registrant columns to the registrations, as the registrations would still be the "registrant", with a pseudo parent entity just being a hash value upon creation. Or better yet, just link all "child" registrations to the initial registration by the registration_id that they were all created from. You would still know that the initial registration wasn't necessarily created by the registrant based on the author_uid being different from the registration's user info. You could easily grab all registrations based upon this parent_registration_id.

In your concept the changes would thus become:
Registrations

• registration id
• author id
• created
• updated

Registrants

• registrant_id
• registration_id
• entity_id
• entity_type
• uid
• mail
• hash

This change arises from the fact that you can have multiple registrants per registration, but each registrant could have a different entity that they are registering for (at least in my head), thus the need to move the entity_id and entity_type to the registrants table. Now the Registrations table becomes almost pointless as it adds no real extra relationship information that you couldn't otherwise just store in the Registrants table.

Just a thought.

I marked #1506536: Make email fields optional for authenticated users as a duplicate.

It sounds like there's a strong consensus to keep everything in a single table, in which case we'd add a UID column and make email optional. I'm fine going that route. It raises a couple questions, though.

• How should we control what values gets set for the UID? In some cases, I imagine we'd want it to be the authenticated user completing the registration (same as author_uid), in others we'd want users to be able to select a different user using, say, an autocomplete field. In the latter case, can a user register any other user on the site? In the former, should we hide / disable the user field? Does there need to be a setting to determine the behavior?
• With this architecture, multiple registrants tied to a single registration could still be accomplished by using field collection, which was our original idea. This solution would need some glue code, however, to ensure that capacity limits are still enforced and perhaps find a way for the email broadcast to find additional registrants in the field collection field. One idea is to have a registration_registrants submodule which requires field_collection, perhaps setsup default fields, and handles the capacity and broadcast issues.

Just thinking out loud ... anyone have thoughts on the above? Also changed the issue title to be more descriptive.

How should we control what values gets set for the UID? In some cases, I imagine we'd want it to be the authenticated user completing the registration (same as author_uid), in others we'd want users to be able to select a different user using, say, an autocomplete field. In the latter case, can a user register any other user on the site? In the former, should we hide / disable the user field? Does there need to be a setting to determine the behavior?

I would venture that it would never actually be shown to the user, instead it is programmatically set to the UID of the registrant for that specific registration, if accounts are created upon registration. Otherwise just set it to 0 to recognize that it was an anonymous registrant. You would still know if another user registered an anonymous user based upon the author_uid column.

With this architecture, multiple registrants tied to a single registration could still be accomplished by using field collection, which was our original idea. This solution would need some glue code, however, to ensure that capacity limits are still enforced and perhaps find a way for the email broadcast to find additional registrants in the field collection field. One idea is to have a registration_registrants submodule which requires field_collection, perhaps setsup default fields, and handles the capacity and broadcast issues.

I guess I just fail to understand why a field collection is necessary. Registrations already are fieldable and can be associated to a parent registration by simply adding a "parent_registration_id" to the registration. Then you know who created the registrations (author_uid of the parent). This prevents having issues regarding capacity limits as it still creates separate registrations per registrant, and allows broadcasts to work as they do now.

How should we control what values gets set for the UID?

Always default to current user. But make that apparent in the form with a message "registering for yourself" or something.

Registration form with up to three elements for choosing identity, with maybe options elements to choose between:

• Myself
• If user has 'register other users registration_type' permission: for other users on website, show username autocomplete.
• If user has 'register other anon registration_type' permission: for random email.

Notably, still need some kind of verification system for anonymous users to un-register.

multiple registrants tied to a single registration

Entity Reference?

Need a framework for contacting people if there are going to be so many people types. A method ($registration->people/registrants/contacts()) which returns a list of user objects, and dummy user objects ($user->mail set) for anon.

@jpontani: I would venture that it would never actually be shown to the user, instead it is programmatically set to the UID of the registrant for that specific registration, if accounts are created upon registration. Otherwise just set it to 0 to recognize that it was an anonymous registrant. You would still know if another user registered an anonymous user based upon the author_uid column.

That was our idea as well: for auto creation of new users on registration have a look at http://drupal.org/sandbox/jelles/1506486, it works both ways, it can prefill fields for authenticated users and it can create user accounts for anonymous users. It works well in combination with #1506536: Make email fields optional for authenticated users.

Hey gang - Just pushed a few commits implementing this thread. Please reference:

• f25813e3e428c13f984cc192016c3f38986f587a: Adding permissions for registering other registered and anon users and altering registration_is_registered() to work for both anon and registered users. Also makes necessary changes to all form elelements per something along the lines of @dpi
  s suggstions.
• 11849619b371c1d56247e23f1c47f831a6a415ca: Adding user and user_uid properties and an abstract method/property for mail that is based on either the user or anon_mail.
• 7736b5c900f79113cd759a489405b8a594c3f5b9: Alter registration schema adding a user_uid column, chaning mail to anon_mail and making it optional, and adding an unique key for users.

I'm assuming this is going to need a few more revisions and some testing, so marking as "needs review" for now. Let me know what you find.

Looks good, love the AJAX implementation!

Some notes:

Registration people

• UI: Eliminate 'myself' option if you are already registered.
• UI: Default select option to 'myself'.
• UI: Change order of options, unix style: Me, Group (other users), World (anon)
• Usability: Select element should not use word 'registered user' as this confuses terminology with Registration, and users already registered for an entity.
• Usability: What does 'anonymous' mean to someone who is not a site admin?
• Prevent user from creating multiple registrations for 'Myself'
• Hide registration form if: register other account == FALSE, register other anon == FALSE and if user already has a registration for MYSELF. (if empty(count($who_options))

Perhaps

• Myself
• User account (Drupal uses 'account' word)
• Email ('Anonymous' word for internal/site admin use only)

Checking anonymous emails in account emails.

Prevent anonymous email if a user account with same email has already registered for this entity.

Rename some permissions

• 'Register other anonymous registrants' to 'Register other anonymous email'?
• Keeping in line with other modules, have internal permission names include name of module:
  change register other permissions to 'registration register other account $type' and 'registration register other anonymous $type'

Anonymous email vs Account email

• Update Manage Registrations->Registrations tab: rename email column and cells should show user account username or email for anonymous.
• registration_send_broadcast() needs to user $account->mail when applicable.
  Change $recipients[] = $registration->mail to mail() method.

Schema

• Change unique index to array('entity_id', 'entity_type', 'anon_mail', 'user_uid') as it trips on
  ('entity_id', 'entity_type', 'anon_mail') when anon_mail/user_id is NULL for multiple entries.
• anon_mail needs to set to NULL when new registration with user_uid is created. Opposite is correct.
• Need upgrade path.

Thanks @dpi, great tips. Most are committed. Also handled setting propor defaults for who is registering field for existing registrations. A few points.

Change $recipients[] = $registration->mail to mail() method.

Not necessary, the mail property is set from the method in the constructor.

Update Manage Registrations->Registrations tab: rename email column and cells should show user account username or email for anonymous.

Chose to have both uid and email col. Convenient for a few reasons, including maintaining mailto links. Users the mail() method.

Need upgrade path

Really want to avoid promising this until we're out of alpha, which will hopefully be soon. Leaves lots of cruft in the install file in addition to time.

Small patch for

UI: Eliminate 'myself' option if you are already registered.

BTW: great improvements!

Make email additional (and don't validate) if a signed in user tries to register other people without an email address.

anon_mail needs to set to NULL when new registration with user_uid is created. Opposite is correct.

Still not fixed. In Registration class: Registration->anon_mail change:

$anon_mail = '', to $anon_mail = NULL,

BUG: If 'me' is only value, multiple submissions are allowed (due to #access) if user does not have 'create * registration other *' permissions.

Expanding on #26.

Adding helper to determine what people types may register for event, from perspective of a user.

Show forms based on this helper.

Please see attached for some ideas.

Edit: Would probably move check in registration_register_page_access() to registration_access() create block.

the update function is missing from the .install file,
this means:

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.anon_mail' in 'field list': SELECT base.registration_id AS registration_id, base.type AS type, base.entity_id AS entity_id, base.entity_type AS entity_type, base.anon_mail AS anon_mail, base.count AS count, base.user_uid AS user_uid, base.author_uid AS author_uid, base.created AS created, base.updated AS updated FROM {registration} base WHERE (base.registration_id IN (:db_condition_placeholder_0, :db_condition_placeholder_1)) ; Array ( [:db_condition_placeholder_0] => 2 [:db_condition_placeholder_1] => 1 ) in EntityAPIController->query() (line 152 of {..}/sites/all/modules/entity/includes/entity.controller.inc).

See #25 and #1512498: Missing db update for mail and uid column changes

-dev is considered unstable at this time.

New path based on #31, there was a problem with anonymous users

Thanks for the feedback. @dpi, I fixed the issue with the anon_email needing to be NULL. @attiks, the 'me' option still needs to be there so a user can switch back and forth when editing a registration. At this point, I want to close this issue as it's too broad. Please create separate issues for any bugs/changes and lets keep issues and patches more singular in nature so they are easier to review and apply.

Thanks again for the support and looking forward to pushing for a stable release.