Hi All
Here at The Leukaemia & Lymphoma Research charity, a lot of events have participants who may be children or where a team leader is booking for all team members. The current implementation of CiviCRM insists on the inclusion of an email address for all participants, which is a problem in the two scenario's. Some of the teams are quite large and each team member has specific settings which need to be captured, such as t-shirt size, route etc.
We've been talking to Lobo & co and have determined that the following change would be improve the event registration process.
CiviCRM should be amended so that instead of adding the single email address field into the form it adds a reserved system profile which contains an email address ONLY IF the profile(s) associated with the registration form do not already contain either an email address OR first + last name fields.
Any feedback/suggestions would be much appreciated, this development is underway so please be quick!
JIRA Issue is registered here http://issues.civicrm.org/jira/browse/CRM-9587
Parvez
Comments
Good change but wouldn't it be more salable long-term if first/last name was not required? I.e. an option for no email or name for additional participants?
We don't use event reg nearly as extensively as you guys so I'm just thinking out loud ;)
Not sure that would work, the participant needs to be assigned to a contact and those are the two minimum requirements to create a contact.
In the situation where someone is registering themselves, and un-named guests, could CiviEvent create a special contact record called "Anonymous Guest", ie first name "anonymous", last name "guest". (This could be a seperate contact sub-type)
I think this would be very useful for fundraising dinners where someone is paying for a table of 10, and has not yet decided who he/she is inviting.
I think the requirement your talking about is effectively tickets and can be delivered using price sets at present.
The pricesets work to a degree for selling tickets, but its not very intutiive to a typical end-user. Perhaps on the page where it asks the user "Do you want to allow multiple participants", it could offer a link/button with the label: Need to sell tickets for unnamed participants? Click to set up a price set for this.
Even then, the search/reporting is not straight forward. Depending if the event was set up to sell tickets vs collecting participant info, will determine how the event organizer gets a head-count. But this is a bit off-topic and is more about usibility.
I think this will be helpful
This is one of 2 major problems that Wellington Circus Trust has with event registrations (so thank you). The other is people not seeing the 'pay later' box - my feeling is that it would make sense to move that box to being right above the submit button - not only for the Circus trust but in general
+1 for reworking the pay later
I'd like to see it moved down to the billing section, and be displayed as a radio button, so it's very clear that you have one of two options for the billing method.
Agreed this all seems to make sense esp for team rego
With Dave and Deepak, we had long discussions and problems and code change around dedupe.
As you might have seen, the special email only vs. profile case complexify significantly the code.
I seem to recall that to work, the dedupe rule can't be the default one, but needs to be chosen. eg. if you have a profile with first and last name only, but the default strict on email, it will always create duplicates.
And if you can have different profiles for the main and the subsequent participants, likely you need to be able to choose different dedupe rules too.
It isn't mandatory to have an email for the aditionnal participants, and in general, despite convenient, having an email is NOT mandatory to attend an event, and shouldn't be to register online neither for the main nor the additional ones. I seems that if you have first+last it's enough?
Instead of a fall back profile that adds an email, I'd have a default profile for event registrations that contains the email. If they change the registration profile and remove the email, that's shouldn't be a problem for civi (ie. it shouldn' be a reserved field).
The verification shouldn't be IMO about adding a magic profile but displaying an error msg if the combination is not correct. Otherwise, you will have case where because one user removes the firstname in a profile it will automatically adds an email. I'd rather have a clear error message than this "weird" behaviour
PS. And we can get rid of the always confusing checkbox about duplicate emails that no one seems to understand
Hey Xavier,
So, to summarise :-
Does that sound about right?
profileS (you can have two in event registrations, and the email or names could be on either (don't care that much about the edge case where the first name is on the top profile and the last is on the bottom one, whatever your implementation does it fine)
X+
I think that these changes are very good. We use CiviCRM primarily for the event registration module. While we do require a unique email address for each attendee (our LMS and online classroom uses this for user names), I have been asked many times why the email address is separated from the profile we use to collect the attendee’s personal information (name, org, title, phone, etc…). It would be really nice to have all the personal information in one section, separated from the fee section. It makes more sense to the attendee that way. I do think that being able to dedupe by email address should still be an option.
I also agree that it would be nice if the pay later box was clearer for the users.
I agree that requiring emails for event signups can lead to cumbersome work-arounds, and like the proposed improvement.