CiviCRM Community Forums (archive)

JMA Consulting has just implemented CiviEvent for a client who is going to be opening registration May 5th, 2008 for an event in June that will be oversubscribed. They identified additional requirements yesterday (April 23, 2008) that they would like to include. Not a great process, but there you go.

I'm interested in feedback on the following client requirements, and expressions of interests from people who can assist in implementing one or more of them before May 2, 2008 for contribution back to the community, assuming the community wants the functionality:

• Allow multiple individuals to be registered from an AJAXified page, gathering FirstName, LastName, and email for the registrants for each ticket price if a number greater than 1 is specified. The payment in this scenario is made by someone who may or may not be registering, eg a secretary registering three executives. A checkbox on the Event Settings page would determine whether multiple registrations could be made at one or not. If yes, then a modified series of the Event Registration pages would be activated.
• Support putting profiles on separate wizard pages in event registration process, with an admin interface similar to the inline/tab choice available for Contact Profiles
• Move the Pay Later info display from second page of registration to first. If the user checks Pay Later on first registration page, hide the Credit Card info section and display the Pay Later info block; and vice-versa when it is unchecked. <change: see comment below>
• Generate and store unique invoice numbers for pay later registrations, and include it in thank you email sent to users (eg via a token replacement scheme).
• Develop a recipe for inserting a Drupal cck type in place of a CiviCRM Profile in CiviEvent. Motivation: allow users to create info on their company or project(s) that is relevant to the event that they are registering for, but is not in a one-to-one relationship with them. For example, several registrants may be associated with a single project, or one registrant may have several projects. In both cases, it would be nice to allow and encourage registrants to provide info at signup. (CiviCRM shouldn't be dependent on Drupal or Joomla! in this way, so a "recipe" for how to do this by hacking CiviCRM is preferred.)
• A work-around to support a waiting list for an event, and selected invitations for people in waiting list to register despite the event being 'full', in the absence of proper support for either a waiting list or moderation of event registrations. At present I am thinking of including an invitation to join the waiting list via a link in the text displayed when an event is full. This link would be a CiviCRM Profile signup that added people to a Waiting List Group. Selected inviduals in this group would then be sent a link inviting them to attend 'the event', but the link would be to a copy of the original event that is not yet full. This isn't a great solution, and I would love to hear other suggestions. <Ideally, a moderated waiting list should be built, but one week isn't a feasible timeframe for that, even though my client may be willing to fund this.>
• Documentation in the form of a recipe for using CiviCRM to export Event Registrants and Waiting List members into a csv file.

We are also interested in hearing about how speakers and panellists who do not have to pay could be registered (so they will get badges and communications etc.). Basically, the client does not want to display a free registration category, and especially one that anyone could signup for. I imagine that proper support for this could be included in CiviCRM once it has ACL support via a mechanism that links the display and ability to select an ticket type with a particular role. Either the event administrator could then register these folks, or they could be manually entered as contacts with an appropriate role and sent emails inviting them to register with the appropriate email linked to that role.

Thanks for the reply, Peter - good questions.

1. It makes some sense to allow a Profile to be provided for each person being registered. I had been thinking of a single line per registrant that would pop into existence on the page courtesy of JavaScript as soon as the number of tickets being ordered exceeded 1. (This type of dynamic modification of the DOM using AJAX patterns is what I meant by the clumsy 'AJAXified page'.) It could be a whole profile though instead of these three fields, which would allow for custom things like meal preferences. One UI issue is that it is necessary to associate the individual registrants with the ticket type that is being purchased for them. So having these profiles appear in a way that integrates well with the ticket types is the main goal here.

One consideration here is that the staff person doing the registration is unlikely to know things like meal preferences, so a smaller set of fields is more likely to be required. Letting registrants come back later, encouraged via emails, to set their individual preferences for breakout sessions and so on, is currently possible.

The current version of CiviEvent also allows one to repeatedly register an individual, and is fine for many cases. But when, as for my current client's current event, they expect multiple registrants from a number of organizations for the event to be done by junior staff, it makes sense for them to optimize the UI for this.

You're right that there is a Pay Later checkbox that comes up on the first page (which I refer to). I suggested moving text from the second (confirmation) page to the first (registration) page, when I should have written from the third (thanks) page to the first (registration) page. These are the Pay Later Instructions for the event from the Event Fees configuration page. It is likely best to add a field for Registration Page Pay Later Instructions in addition to renaming the existing field to Thank You Page Pay Later Instructions. Most people will likely put the same or similar text in both places.

And Dave has just pointed to this http://issues.civicrm.org/jira/browse/CRM-2703 as the fix for that problem which is in the 2.1 queue. Not sure if voting on JIRA for things to be fixed is noticed but maybe it helps.

We've posted a detailed description of how we plan to implement the "Option to Register Multiple Participants During Online Event Registration" ...

http://issues.civicrm.org/jira/browse/CRM-3086

I think the plan covers the "consensus" in the discussion below - it uses the configured profile(s) to collect info for EACH participant, and allow each participant to be registered for a different fee level. Please look it over and get back to us w/ any feedback as soon as possible.