The focus of this issue is to evaluate architectural approaches for the attendee/event management functionality in COD for Drupal 7. This functionality is provided in the Drupal 6 version of COD by the Signup and UC_Signup modules. We should maintain the same functionality in Drupal 7.

The main questions to answer are:

Which module should power attendee management functionality in Drupal 7? (currently powered by Signup/UC_signup in COD for Drupal 6)

and the main candidates for providing this functionality are:

A) Straight port of the Signup module:

Signup currently has a "straight port" in progress of the 7.x-1.x branch.

The "straight port" approach has the benefit of generally being faster to write, but the drawback of not taking advantage of the Drupal 7 Entity API for storing signups. The Drupal 7 entity API helps to simplify the popular feature request of adding event-specific fields to the signup form, and may also help provide better architectural compatibility with Commerce.

B) Extend the Entity registration module.

What is the recommended approach for integrating signup-enabled events with Commmerce products and orders?

Commerce has a different architecture for making products signup-enabled than Ubercart had in Drupal 6. What's the best approach for Commerce + Signup-equivalent integration in Drupal 7?

A background on some of the technical issues involved

#1285384: Entity based registration module for Drupal 7.

Key point about schema:

#1473008: Adding user uid and making email optional

A summary of the essential attendee management functionality present in Drupal, from:

http://groups.drupal.org/node/138619
Main goals of a signup/registration-type module for Drupal 7 are:

Registration

  • Integrates well with Commerce
  • Sign up one or more users for an event
    Entity Registrations: Currently possible by using field_collection combined with whatever individual fields are needed. Challenge here is how much of this should be done by creating a bunch of fields in code when registration_registrants (just an idea) module is enabled, etc. Could also move some of this more into core/code by creating a separate registrants schema.
  • Set a limit on the number of attendees for an event and see/display how many spaces remain in a specific event
    Entity Registrations: Yes
  • Assign different Signup statuses used to group registrants
    Entity Registrations: Need to add a status property to the Registration entity. (pending, paid, canceled, etc.)
  • Each status can have its own signup limit for an event
  • Each status can count against the total signup limit for an event
  • Control which user profile fields display in the signup form
    Entity Registrations: Yes
  • Create an account for users who do not already have accounts and enter necessary Signup and profile field information for them
    Entity Registrations: Yes
  • Allow existing users to edit their profile information as part of the signup form
  • Free or Paid registrations:
    Provided in Drupal 6 through the UC_Signup module. Note, the paid event signup workflow through UC_Signup in Drupal 6 was different than for free events. In Drupal 7, ideally we can make these workflows more similar by moving more of the uc_signup-type workflow into whichever module powers signups, so that it can apply to free and paid signups.
  • Customize the order confirmation email to include created Signup IDs
  • Provides event-specific fields on the event signup form (or is built in a way that this is possible to add later)

Managing Registrations

  • Communicate with registered users (broadcast email)
    Entity Registrations: Broadcast feature exists and works well, except for case of a single user registering multiple registrants.
  • See how many people are registered for a specific event
    Entity Registrations: Yes, also views available
  • Manually sign up or cancel the signup of a user
    Entity Registrations: Yes
  • See a log of all signup IDs and email addresses associated with my order
    Entity Registrations: Yes
  • Work with purchased signups in the same way as free Signups

Comments

kclarkson’s picture

Issue summary: View changes

Added goals of the registration module

kclarkson’s picture

Issue summary: View changes

spelling

kclarkson’s picture

a) Integrates well with Commerce
After review there is a commerce registration module that provides basic integration.

A patch or additional configuration may need to be developed to match the workflow of the free event use case.

example: Paid events currently have registration as part of the checkout workflow which would not match the workflow for basic registration for free events.

kclarkson’s picture

b) Maintains feature-parity with the existing Signup and UC_Signup modules:
- As an event organizer:

-- I can send an email to everyone who is registered for a specific event
YES - Emails can be sent to participants. The email settings also allow you to select what lists to send to

-- I can see how many people are registered for a specific event
YES - The Manage Registration tab appears at wich you may view registrations

-- I can set a limit on the number of attendees for an event on a per-status and total basis and see how many spaces remain in a specific event
YES - You can set the limit of attendees as well as a start and cut off date.

-- I can manually sign up or cancel the signup of a user
YES - In the registration settings for each event.

-- I can assign different Signup statuses used to group registrants.
YES - This would be an additional field in the Registration Type field settings.

-- Each status can have its own signup limit for an event

-- Each status can count against the total signup limit for an event

kclarkson’s picture

Issue summary: View changes

More detailed summary.

mshaver’s picture

Issue summary: View changes

reorganizing feature list

japerry’s picture

Additional details for multiple user registration (taken from linuxfestnorthwest.org/register)
--Free or Paid (reg_type)
--sub products (multi-day with different costs)
--Mulitple users (and how many)
Since we check their email addresses, we could potentially create a list of email addresses with corresponding checkmarks indicating which registration each should have (which sets the 'reg_type' variable to the email)

Once you press continue, the email addresses will validate, and if the user has any valid data already, it will be populated (but not shown) to the next registration page.

If there is a multiple product reference, it should have a select or a checkbox depending on if users are allowed to be a part of multiple registration.

Each user will get a chance to register, and when that is done, the ones that cost money (are line items) will be added to the cart and shown the checkout form.

If all were free, it'd show that the users were successfully registered and the process completes.

japerry’s picture

Ezra started another conversation here, but I think its pretty much summing up what we talked about here..

http://drupal.org/node/1663222

japerry’s picture

Issue summary: View changes

Add link to schema issue.

japerry’s picture

Users without an e-mail address:

You cannot register yourself without an email address -- however you should be able to register other people, once you place your email address in.

The workflow would be something like:

1) User Creates registration/user account or anon email
2) User creates additional registrations with a first/last name in lieu of an email address
3) User can see the registrations, whether they were email addresses or non-email addresses.

To see people who are registered, its based off of the entity registration and not the user.

japerry’s picture

Status: Active » Closed (won't fix)

We're using the ticket module now. Registration module doesn't give us the fundamental ability to attach different types of registrations to events.