CiviCRM Community Forums (archive)

@lobo,

I just tested it on the Demo Site, and that scenario works fine. A user can register multiple participants at once, none of which are him/herself.

@xavier,

Maybe I haven't understood your concern. To me, the 'same email address' question is a completely different concern. It's not related to whether a person can register other people. It merely prevents anyone from using an email address to register that has already been used by another participant.

So although I agree that that option is often confusing to end users, I don't see that we need to change it for this situation. Please clarify your concern if you feel differently.

The select with those 3 options will only replace the current 'Register Multiple Participants' checkbox. No changes to the 'same email address' checkbox UI or behavior are being proposed.

As for option 0 + 'allow same email', it's probably an unlikely edge case, but it is conceivable.

For example, you might want to force people to register for themselves, but you might not care about e-mail uniqueness.

I.e., several people from the same company can register with general company mailbox address, but each person needs to register for themselves in order to confirm personal eligibility to register. (e.g., eligibility may be dependent on data associated with the CMS user account.) Again, I'd bet this never actually happens, but it could.

Personally, I think the 'same email' option is usually redundant with the general contact matching rules, and so i think for usability, it could be moved into an 'Advanced options' fieldset which is collapsed by default. But that's outside the scope of the problem we're trying to solve here.

Matt - sounds like we have consensus for your approach. If you're able to include the form modifications etc. as described in my comment on the issue tracker then we can get this into 3.3.

Did this ever get completed, and if so in what version? I am running 4.0.6 and it is still the same simple check box, not the select list. Being able to prevent users from registering others is quite important to our application.

No, it was never implemented as spec'd above. We used a different solution for my specific project, but I think the above is still a suitable generalized solution.

As far as I know there was no work done, and it's definitely not part of the 4.1 queue (4.1 is in code freeze). This could become an MIH for 4.2 if there's seed funding.