Implementation ideas

When someone registers for an event, you often require some event specific information, for example food preferences, whether they need a parking space, or which sessions they want to attend.

This information has little value beyond the event, but for smooth running of the event, it's essential. Most often there is some information that is captured for all attendees regardless of ticket type or attendee type, for instance their badge name, and usually this common information is processed in a way that's the same for all . E.g. producing badges.

I see several possibilities:

1. Store it in some custom table. Write a suitable module for capturing the data and outputting as required. This has the advantage of being able to customize the data structure. For instance, it would make group bookings easy. More code is needed than leveraging an already working project. The lovely Form Builder might be persuaded to work with this. Multipage data captures might be difficult; the custom table might be more than one table. Pageroute might be used.

2. Store the information in a webform. This has the advantage of some data security: webforms are not content and are not displayed as nodes. The webform is never indexed for search. But webforms are flat structures: a group booking might need another structure to track the group. Different ticket types/ attendee types at events often have different data gathering requirements. Sometimes a webform can be shared between these ticket types/attendee types, other times they can't. Non-shared forms make reporting difficult. The Webform Report module, with fixes for the security issues might help. Multipage webforms might be achievable using the Pageroute module.

3. Store the data as a CCK node type. Upside: CCK is good at handling shared data and has lots of widgets. Upside: excellent Views integration. Again Pageroute could be used. Downside: nodes are searchable and this could lead to information leakage. Downside: this data is transient and once the event has concluded it should be discarded. That means deleting this information.

4. Store the information in a Signup. Signup lets you include forms and can serialize the form into the signup log. describes this. Upsides: Signup already exists, and there are some useful add on modules. It's integrated with Views. Downside: Signup doesn't do group bookings. Reporting on serialised data is expensive. Maybe Webform Report could be extended to deal with Signup data.

In my view we have:

• People and organisations we know something about, who are not yet users of the system. Drupal has no concept for this sort of person. CivicCRM does. We may have an email address, but not necessarily. An example might be people on an invitation list; we will want to produce a letter or mail for these people, but they haven't registered.

• People who have registered for an event, who also want an account on the system. It's for events where there's a good amount of information on the web, which is only available to participants or registered users. Or where the event is an offshoot of a community site. If someone has a login, then we can use profile data to fill in event fields during registration.

• People who have registered for an event, who don't want or need an account: anonymous registrations. Organizers want to know about these people for the future. And of course need to track their attendance. But the attendee isn't interested in a longer term connection to the site/community. We can create accounts for these people (although we might not have their email addresses) but they should be noted as dormant. This info is not available during subsequent event registrations. We may also have multiple registrations of the same person, so it may be useful to have some account reconciliation tools to combine accounts.

• Registrations at the event. This is usually similar to normal registration, but data input is optimized for speed, and includes badging, and often this data will need to be backported to the live site, if it was collected offline. IMO it should be collected in the same structure as pre-registrations.

Constraints: Drupal only has the notion of a user as an account holder. It wants every account to be associated with an email address.

Implementation: I can see three possibilities -

• Have a separate table for people known to the system, who are not registered users, and refer to this for in the wider events handling. Simplenews maintains it's subscribers table, independently of the subscribers Drupal site registration. RSVP module keeps a list of invites to an event, and connects where possible the invitation to a known user. Signup similarly, I think, can deal with anonymous registrations.

• Everyone known to the system has an account. Where the email address is not known, a dummy that follows a well-known pattern is used. People who have never registered but are known to the system are given a particular role, e.g. the 'prospect' role. The system would need account reconciliation mechanisms to allow people to register on the system despite already being known to the system. This would be especially required where they were already known to the system as a prospect with an email address since Drupal requires email address to be unique. (Why??)

• Don't track prospects and people who have indicated that they are not interested. Disallow anonymous registrations. (May be a problem with group bookings.) To the extent that you want to talk to these people, hold them in Simplenews. Create event registrations using the system you use (CCK, webform or whatever) and only create accounts for people who indicate that they want them, or if they are required to participate in the event.

I can see several ways in which it can be done:

• Everyone who registers gets a user account. Nobody who has not registered has an account. This works fine for single event sites where the event is the site. It doesn't scale.

• Or, when someone registers if they aren't a registered user create an account. Give them a role that confers registration.

  This can work for a small number of events, but you get a proliferation of roles when you run lots of events. If your site is complex with lots of modules, then permissions for the roles and making sure that they are right can be tricky. It might be okay if the role creation was automated. For example, a new attendee role for a conference could be based on the authorized user role + permissions relating to the particular event. You may need more than one role for the same event, to represent different ticket types. Views works nicely.

  Event data could be stored separately from the person, but you would need a link module to create Views. Or if event data is stored as a CCK type, then you needn't. You would end up with one CCK type for each ticket type, and different event might need different node types to store the different data collections. CCK would work nicely with the shared data gathering.

• Or, when someone registers, give them an account if necessary, and a user flag.

  This means that everyone who is an attendee needs an account. You get a proliferation of flags. Creating lists of people is easy though. And Views works nicely.

  Everything above about storing event data separately or in CCK still holds true.

• Or, use a User Queue. One per event. It works like Node Queue.

• Or, when someone registers, they get an entry in a webform. Different events have different webforms. A user account is not required to make a webform entry.

• Or, store the registration in a CCK, giving anonymous users the right to create bookings, a CCK node type. User reference to link to people who are registered users. Either create a new CCK per event, or use nodereferences to link to the event.

• Or, use the signup module to track registrations. Extend to group registrations.

• Or, build a custom module for registrations. (We already have Signup, but it's not group friendly, and holds form data as serialized.)

• Or, through Ubercart, you have a product purchase.

Other ideas?

If the event is a one-off, with a custom site, then this isn't likely to be an issue: everything can be hand-built.

If the event is one of a series of free events, without complexity, then installing Signup, enabling it for a node type and setting up each event as a node is not too hard.

For larger scale, complex, repeatable events, setting up everything from scratch is overhead. Ideally you either want a template (not in the Drupal design sense), with tickboxes to say 'I want an RSVP and a wait list for this event', or you want to be able to clone the structures used in a previous event.

For events built around OG, Node Clone might work. (Not tested.)

Possibly a combination of Space, Features and Context might work to provide a platform for event repeatability.

Or Patterns.

and i do think that its a fairly non-trivial piece of work

lobo

I only had a chance to briefly skim this post, but LOTS of what's being discussed here is all handled by the Signup module. Before anyone spends too much effort redesigning an entire system and implementing something from scrath, please take a look at what signup (and a host of add-on modules that integrate with it) can already accomplish. If anything is missing, I'd be very happy and willing to work with people to either add it to signup itself or a separate module that works with it. Let's avoid Druplication if we can...

Thanks!
-Derek