COD 6.x-1.x supports a range of event registration options through the UC_Signup, Signup, Ubercart and Signup_Profile modules.

To help with development of the Commerce_registration module and specifically to move along #1150318: Upgrade the cod_events Feature to D7, it would be helpful to document all the various permutations that are possible in 6.x-1.x, so we can make sure they are accounted for with a smooth user experience in 7.x-1.x.

Let's update the issue summary and mark as fixed when we feel we've covered the main use cases:

Person being registered

  • Self
  • And/or Others

Number of events registered for

  • Single event
  • Multiple events

Event cost

  • Free
  • Varying cost

Using a coupon?

  • Discount coupon
  • Multiple redemption coupon

In the 6.x-1.x paid registration workflow, we do::

1) User adds each event to cart with qty reflecting # of people signed up for each event
2) Events are listed, one email address field per attendee. Purchaser submits form.
3) For each attendee: If there is an account associated with that email address, the user does not have to re-register. If there is not already an account, the purchasing user is prompted to enter (configurable) required fields for that user's profile.
4) Ubercart/Commerce checkout process takes over, accepting payment and any coupons.

It seems like steps 1-3 could potentially be handled by the Registration module for both free and paid events, and that Commerce_registration could handle connecting steps 3-4 via #1500132: Allow reverse workflow of register to checkout instead of just checkout to register.

Comments

levelos’s picture

Thanks for getting this started Ezra. I'd suggest that we have Registration handle the account creation when anonymous users register as that could be a fairly common use case even without paid registrations and the requirement of Commerce Registration. We actually need this for a project we'll be launching in the next week or two, and would be happy to discuss implementation to make it the most flexible. I would imagine something like:

  1. Having a registration admin setting on whether accounts should be created for anonymous registrants
  2. If set and an anonymous registration is taking place, look for a user account based on email.
  3. If not found, present the user with the user account form and create the account on submission
  4. Link the registration with the user id in either case

I'm sure I'm missing something here, but perhaps a starting point.

jpontani’s picture

japerry’s picture

Status: Active » Closed (duplicate)

related to http://drupal.org/node/1496646 -- re-opening because its not quite the same

japerry’s picture

Status: Closed (duplicate) » Active