CiviCRM Community Forums (archive)

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.

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

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.

 

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