Issue with CRM-3086 (Option to Register Multiple Participants)

[mhansen4]

I have been strugling with finding a way for multiple participants to register under a single email address (ie. husband and wifes). I found CRM-3086 and read through the write up.

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

This seems like a possilbe solution to my problem. Knowing this has been worked into CiviCRM 2.1 I tried it out on the Sandbox by creating a new event called "Free Test Event" and ran into a problem.

In the write up for CRM-3086 it states that the:
-------------
After submitting the initial registration page, including any embedded Profile field(s) and billing info, they will be presented with a new page (form) to complete for each additional participant. Each of these pages will contain the configured Fee Levels form element (radio buttons), an optional email address field, and any profile fields configured for the event. (Example: If the event is configured to include a participant field for Meal Choice - this field is presented for each additional participant.)
---------------

What I found though was that the email address for any additional participants was not infact optional but manditory.

This again caused me the same problem both a husband and a wife could not share the same email address.

Does anyone have any ideas in regards to a work around for this issue.

Thanks
Mike

[Dave Greenberg]

We use email address uniqueness to prevent folks from accidentally (or maliciously) registering multiple times for the same event - and email address is required.

Some alternative approaches for your use case are:
* Provide instructions telling people to use an alias email (or fake one?) if they must register multiple people and don't have unique email (probably to kludgy?)

* Forget the new multiple participant feature and use the Price Set feature instead to allow users to give a number of registrants (with a price per person). This approach is decent if you don't care about creating separate contact records for each participant.

* Hack the code to bypass the unique email check. Ping us on IRC or post back here if you want info on this. No idea how complicated a change this would be.

[mhansen4]

David,

You are right on the money with everyone of your comments. Suggesting a fake email address would be to kludgy and would also break the email confirmation. We also need to be collecting contact info for each individual registrant so the price set option is out. I would be ok with hacking the code but I am worried that I would run into another undersired problem of the wrong contact records info being updated.

Thinking this through a little bit more I have another idea. It does however go against a few of the things you are trying to acheive by using this method to check for duplicate registrations.

When the duplicate email check occurs, if a duplicate email address is found instead of dening the registration what if you asked the registrant to confirm the duplicate?

For example if I submitted a registration and the system found a duplicate email address. It would show me the First and Last name (or other combination of info) of that contact. It would then ask me if I was that person. If I answer yes then my registration would be rejected (as it is done today). If I answer no to the identity confirmation then a new registration would be created.

What do you think???

P.S. This might also be a mechanism you could use to allow people to edit existing registrations.

I appreciate you time and thought on this matter.

Mike

[Donald Lobo]

Mike:

At some point, we might decide to resolve the issue of processing a contribution / event reg without an email address. 2.1 is past code freeze and not doabble then. We'll consider it in a later 2.x release

Showing information based on an email address would move into privacy issues that we'd like to avoid

On the other hand, getting a free email address is relatively cheap and quick these days, so not sure that dealing with this is crucial either

lobo

[dharmatech]

Hey Lobo.  My two cents: I think this is an important issue to address in a future release.  Telling your constituents to get a new email address or use a fake one is unrealistic and simply wont happen.  Many households (husband & wife) still share the same email address and never want to give it up.  And Mike's use case is common and will become a bigger issue as 2.1 is used.

thanks
tony

[SarahG (FountainTribe)]

I think this is an important issue as well. I would like to use CiviEvent (with Option to Register Multiple Participants) to allow a parent to register their children for Sunday school.  I don't think my organization is unique just because most 5 and 6 year old kids attending school do not have an email address.

Perhaps this could be solved by showing the person who is attempting to register, all the members of their household. Then they could simply check off their spouse/kid names as a  participant.

 

[mhansen4]

Dave / Don,

Don't get me wrong I understand that 2.1 is just about ready for release and I am not trying to con you into slipping this in. I do however want to raise the issue and possible get some discussion going. Like a lot of people I am not a programmer so helping write the code for this piece is outside of my abilities. I would however be happy to participate actively in a discussion like this to come up with ideas so a solution can be found that will work for all.

By the way there are a lot of really cool new features coming out in 2.1, GREAT JOB!!!!

Mike

[mhansen4]

I hear what you are saying about displaying personal information.

To prevent multiple registrations what if there was a simple confirmation if someone was trying to register using a email address that was already used to register another participant. This could look like a simple question: "Some else has already registered using this email address would you like to edit the email address or continue".

At the same time you could be giving out a random confirmation number with each registration. This confirmation number in combination with the email address used to register a person could get them in to edit their registration. A mechanism like this would keep personal information protected.

During the editing process of a registration if a refund becomes necessary you could let it be known to the participant that all requests for a refund must be reviewed by a organization representative. The Org Rep could then manually refund the amount. This would be a easy way to implement a feature like this with out the complexities of trying to work out automatic refunds. You can save that for a future release if it is something you want to tackle.

You might even have a option to email all event confirmation codes registered with the email address entered. This would allow people to double check registrations or retrieve lost registration codes. 

Mike

[Donald Lobo]

Mike:

as mentioned previously, we will consider implementing this / variations of not requiring an email address in a future release. We are in the midst of the 2.1 release cycle and I'd like to avoid getting into a discussion of "what-if-we-do-this". At the same time, i'm looking into the code base to see the implications of making email optional.

There are multiple other ways of giving back in addition to code contributions. You can check the below for some ideas and specific things

http://wiki.civicrm.org/confluence/display/CRMDOC/6.+Get+and+Give+Help
http://civicrm.org/node/142
http://civicrm.org/node/407

Looking forward to your contributions

lobo