Allow duplicate email addresses

Updating to 4.7.x-dev.

No thanks, this is by design. Setting to "by design" unless there is a good explanation of why duplicate email addresses are a good thing.

Should be an option - some people like to have different accounts for different "hats".

With drupal being used in ever more complex ways user psychology becomes important, and basically that means "maximum flexibility".

Unless there are real programming or other technical problems, there should be an admin option to allow duplicates, even if it comes with warnings that it is not wise unless essential.

Alternatively, perhaps it would make sense as a Module rather than a patch - all that matters is that Admin can get the functionality if they need it.

Cheers

Yep. So somebody make a module. Leaving at by design. Different "hats" are not the solution here....implement a personas.module that can be linked to a single user account.

I too have found this somewhat arbitrary “by design” restriction very annoying and unexpected. At the very least, an admin should be able to “bless” certain eMail addresses for multiple use by “users.”

I'm not sure I fully understand the "By Design" argument here. Part of the goal of Drupal (per my understanding) has been to create a flexible CMS that can be molded to create the solution that is needed for a given site. By kicking out suggestions of this nature on a claim that it is "By Design" appears to go against that.

Rather than asking for reasons why it shouldn't be tagged "By Design" lets hear some answers why it SHOULD be "By Design." As long as we do not modify the default then I see no problem with this. Will I use it on any of my current sites? No. May I need it in the future? Who could possibly answer no to that?

I also believe this is by design. Here are some reasons:

1. Every other website I can think of works this way: one user has one account.
2. When doing "forgot password", it would end up resetting the password for all accounts associated with an e-mail address, which would be confusing for users.
3. From a usability standpoint, if I attempt to create an account somewhere and it tells me that my e-mail address is taken, it's a nice indication to me that I created an account here at some point, so I don't need to waste time going through the steps to register.
4. It's a spam deterrent; it prevents someone from signing up 500 times from the same e-mail address and leaving bunk comments.
5. In any case, any desired behaviour of the registration form for someone's custom site can be worked around with form API magic -- simply override the registration form's default validation function. No patches required.

It appears that the desired behaviour is for a single user account to have more than one username associated with it. This functionality can be achieved by giving the user "change username" permissions -- then they can alter their name at will. Allowing duplicate e-mail addresses would just create multiple, disparate profiles that had no connection with each other in any way, and this would hardly be desirable for 99% of use cases, since users would now need to re-enter everything they input in their first profile, they wouldn't have all of the posts they made in one place, etc.

Unless there's a more technical reason to allow duplicate e-mail addresses (if integration with a third-party authentication mechanism required it, for example) other than "Someone might some day think of a reason we might need this functionality at some point," then it doesn't make sense in core.

By the way, to respond to DVkid's comments.

Yes, we're attempting to make a flexible CMS that can do anything under the sun. However, it's important that in the process of doing this that we keep core small and light and cruft-free.

Core's focus should be on making itself as extensible as possible, so that you can do things like not make e-mail addresses required if you don't want without having to hack core (which you can, with the form API). Core's focus should *not* be on including every feature we can think of just in case it might be handy -- that's what contrib is for.

The onus is on any new core feature to *prove* why it is useful to a broad spectrum of sites or why it makes the platform as a whole more extensible. It's not on the core developers to *disprove* why a feature shouldn't be allowed in. And this is a good thing. Otherwise, we'd be stuck with 100+ core modules, a 500MB download for Drupal, and 8 years in between versions. ;)

I've just upgraded from 5.15 to 5.19 and unfortunately now have this feature enabled by default. This means I'm getting duplicate accounts starting to accumulate.

How could this have happened??

It turned out to be a contributed module issue, Bio: http://drupal.org/node/533880

http://drupal.org/project/sharedemail