Requiring access to a non-primary e-mail inbox (that may be used by multiple users!) for registration

Note up front: I will use our concrete use case with pharmacies in the description, but the general question boils down to: CB registration requiring a verified non-primary e-mail address that is possibly shared by multiple users. UserA verifies registration by proving access to myemail@email.com, and UserB ALSO verifies registration proving access to myemail@email.com, and this is sufficient for us.

---
We are in the process of building a web site specifically targeted at one group of professionals, i.e. people owning a pharmacy (note: multiple partners may run a pharmacy together).

To verify registered users are really pharmacists, we want to require verification of access to the 'official email address' of their pharmacy. (such a thing exists here in Italy, called the 'PEC' email inbox). This is NOT their primary email we want to use to send them communications on the site, etc... But they should provide this email, and verify ownership, just once during registration, so we know they have access to this inbox.

Note that different users may use the same 'official pharmacy inbox', which is fine. User A and User B can work for the same pharmacy.

Any insight in how we might go about this would be highly welcome. Our current thought is as follows for the CB registration process:
- primary email can be anything, and will be unique per user like Joomla! requires. It's the 'personal' email of the user. We do NOT bother the user with a verification link to this one.
- we also ask 'what is the PEC email address of your pharmacy' as a separate CB registration field, and to THIS address we send the verification mail that they have to click to complete registration. (again, without any system check to see if other users already used that email address in their registration, which is perfectly ok, they are just different users associated to the same pharmacy)

Thanks for your advice! Is what we want possible? If so, how should we do it, i.e. which CB plugins/workflows do you think we should best use?

Kind regards,
wouter

(I just want to share one approach that we did and it works, to help others with this problem, and it's a great CB Auto Actions use case, but I would still love an answer to how to implement the: primary email is unique, but SECONDARY email is asked at registration, and verified with a confirmation link, and NOT enforced to be unique.)

Just to share: the following flow will 'allow' duplicate primary email addresses, using the CB Auto Actions plugin.

The general principle is this one: myname@gmail.com and myname+something@gmail.com are THE SAME email address (i.e. mails to both arrive at myname@gmail.com inbox), but Joomla! will accept them as 'different' addresses.

(outlined in more detail here: www.joomlapolis.com/news/18328-sharing-email-addresses-between-joomla-accounts )

So what we do is, right before saving a new user's data, we modify their email 'on the fly', adding a +suffix comprised of the exact date+time of registration, and then saving that new address, which is surely unique. The confirmation link will arrive in that inbox just as normal, etc etc.

To do this, we created a new CB Auto Action as follows:
- type is 'code'
- trigger is 'onStartSaveUserRegistration'
(- access is 'all', user is 'automatic' or whatever you need it to be...)
- method is 'PHP (eval)'

And finally the code is as follows:
... This will result in newly registered users being saved with email addresses such as myname+20130603_173019@gmail.com. And the next user that registers with myname@gmail.com will actually be stored as myname+20130703_112233@gmail.com or something, thus ensuring Joomla! never complains about non-unique addresses.

(It ALSO means that your users will obviously need to log in with their USER NAME, not their email address, because they will not know/remember that they are known under this 'uniquefied' email address)

Thanks for sharing this nice solution!

Also thanking you for sharing this with the community.

I also have some improvement ideas.

Your users will be registering and giving their
email address (primary)
and another email address (can be a CB email type field) called PEC address.

Your CB Configuration workflow will be set of course to confirm email required, but you would empty out the CB Configuration parameter so CB does not send any confirmation email to the primary email address.

Instead you will create an email auto action that sends relevant information about the new applicant along with a URL to confirm (you would have to construct this manually in the email message - not difficult).

This way your PEC email will be getting the information they need to access if the applicant is ok and if yes, then they will click the confirmation link.

Only drawback here is that the primary registration email is not confirmed in this process (unless the PEC somehow does this on their own).

Hi guys,

Thanks for the quick replies and thanks words! Feel free to share the solution I outlined in your documentation page about the +suffix duplicate email workaround or whatever. (credit for zerodd.it would be nice, but if not you can always just say it was first proposed by Wouter Smet )

I am intrigued by your suggestion nant, to simply construct the confirmation e-mail 'manually' myself, including the confirm URL, and send that to the PEC address they specified rather than their primary e-mail address.

I had a look at the confirm email, and it looks like this:

www.socialfarmacia.it/index.php?option=com_comprofiler&task=confirm&confirmcode=reg002112d35c0fdba124e7f4d17d9c46130cc67472&Itemid=133

Are you saying that it is fairly easy to construct this 'confirmcode' parameter based on the email address it is set to confirm? (And/or I'm guessing the itemid is the newly created user id?) That would indeed solve our problems. The steps would then be the following:

USER SIGNS UP AND PROVIDES:
- primary email address
- PEC email address

WE CATCH REGISTRATION FORM AND DO THE FOLLOWING:
- do NOT auto-send confirmation mail to primary email address
- fetch/calculate the confirm code of the primary email address (or, well, of the user account, maybe it is just the stored unique user id that's used to build the confirm code) and/or the 'itemid' parameter.
- use the email auto action to send an email to their PEC address, which says: click on this link to confirm your account: www.socialfarmacia.it/index.php?option=com_comprofiler&task=confirm&confirmcode= [CALCULATEDCODEFORTHISUSER]&Itemid=133

THE USER
- sees as only confirm email the one we sent to the PEC address. He clicks the link there, and proceeds as a fully 'confirmed' user.


=====
I agree with your remark, it's a shame we don't confirm the primary email in this scenario (which the communication will happen on), but ok we can ask to enter it twice during registration perhaps. The client wants a confirmed PEC address more than anything else, and we don't wanna bug the user with going in TWO inboxes before completing registration, so whaddoyado

Are you saying that it is fairly easy to construct this 'confirmcode' parameter based on the email address it is set to confirm?

You can manually construct a confirmation URL using the below in your email.


This would for example let you use CB Auto Actions and an Email action to send confirmation emails out to whatever email address you want (you can supply substitution supported To address).

USER SIGNS UP AND PROVIDES:
- primary email address
- PEC email address

WE CATCH REGISTRATION FORM AND DO THE FOLLOWING:
- do NOT auto-send confirmation mail to primary email address
- fetch/calculate the confirm code of the primary email address (or, well, of the user account, maybe it is just the stored unique user id that's used to build the confirm code) and/or the 'itemid' parameter.
- use the email auto action to send an email to their PEC address, which says: click on this link to confirm your account: www.socialfarmacia.it/index.php?option=c...confirm&confirmcode= [CALCULATEDCODEFORTHISUSER]&Itemid=133

THE USER
- sees as only confirm email the one we sent to the PEC address. He clicks the link there, and proceeds as a fully 'confirmed' user.

Yes, exactly this is doable.