currently the email address must be unique for every registration in a registration form. I can think of many cases where this is reasonable. However, there are also cases where it should be possible to register multiple registrants over the same email address:
We recently had the case to host an event for several business executives. These people typically don’t like to hand out their personal address and like to use a general purpose email address (e.g. firstname.lastname@example.org). Now, if more than one person in the company uses this problem we run into problems. Another case would be that a team assistance is given the task to register several managers without using their personal mail. The assistance would like to use his/her address.
A way to solve this is to add a setting in the registration form to “allow multiple registrations from the same email address” and remove the constraint from the respective database table. I don’t see the point of being this restrictive there (given that we are just talking about registrations with no indico-account).
Funny, because we had a similar post a few days ago:
I think this is definitely a use case that we should address in some way. I’m not sure whether removing the uniqueness constraint is the way to go, though. Another thing I had thought of were “lightweight registrants”, who would basically be registered by another person and linked to him/her. They wouldn’t have the same privileges as a normal registrant, but the organizer would nonetheless be able to print tickets for them, etc…
I think there are two different situations at play here:
People who just don’t want to provide their e-mail;
Participants who by definition have no e-mail address (e.g. children) or “collective participants” (e.g. families).
I believe the second one is a very reasonable use case, but I’m not that sure about the first. We have to keep in mind that not requiring an e-mail (or allowing duplicates) will mean opening hand of what is currently the only way we have to unify participants across events. From the moment the e-mail stops being a “primary key”, we can no longer trust that a certain event belongs on someone’s profile. That applies to everyone on the system.
Maybe I didn’t explain the best way: the problem is not having two identities with the same e-mail - it’s that those two identities belong to different people. We do allow the same person to register on two different forms, but if we had different people registering with the same e-mail, then we couldn’t assume the e-mail to be a primary key (of the person, that is).
one way to overcome this for indico could be using the rfc5322 comment feature. This needs probably some hinting for inexperienced users (in the text for the email fields and the error message):
the local part of the email adress may include a’comment’ (a string enclosed in “(” and “)” ) that is ignored for delivery, but can be used to make the string unique for indico.
I does not yet work as the the indico email verifier currently disallows this.
The other thing that should work on most mailservers (sendmail-based. posfix and gmail are typically working) is using the ‘Alias’-feature: A part after “+” in the local part lets the mail go to the same inbox.
(e.g. xxx+1@somehost, xxx+2@somehost). This is allowed and working in indico as well.
See e.g. here.
The lightweight registrants idea sounds very good, because the other family members wouldn’t need access to the registration at all. We just need the feature to place the number of attendees and maybe their names in one registration and to see the total numbers of attendees at the end. That would be awesome. Indico provides all the necessary features for all our other scientific events. Just the open day and other family events are a problem.
That is quite an interesting approach, I had no idea such a thing even existed (only +, which doesn’t seem to work everywhere). So, I guess the e-mail of a particular participant (e.g. someone’s family) could look like john.smith(bob-smith)@example.com?
That would indeed solve the problem with having a unique identifier.
I’m unsure about using this option for delegation workflows (e.g. secretariat(albert-einstein)@example.com), since we’d still like the person’s Indico identity to be linked regardless of whoever does the registration. Maybe a separate feature, something like a contact_email field that defaults to the person’s e-mail, would be an option?