I'm thinking of using Drupal for a gaming site that I'm going to run, but would need to allow more than one account to exist for a single e-mail address (i.e. A person may have three characters/accounts in the game that he'd want separate web site accounts for, but they all use the same e-mail).

Presently, when I try to test this by creating an additional account using my own e-mail address, I get an error message, "The e-mail address (my e-mail address here) is already taken."

I've searched Drupal.Org, and have looked into trying to set this in the administrator function, but can't seem to find it.

Anyone know how this would be done?

Thanks,
Tim

Comments

tjandt’s picture

Hmm, five weeks and no comment, not even a flame??

Anyone know how to allow the same e-mail address to be used for multiple accounts?

Chris Johnson’s picture

There is no administrative setting which will allow multiple accounts with the same e-mail address at present.

If you know any PHP programming, you can take a look at the function user_edit_validate($uid, &$edit) in modules/user.module in the section with the comment "Validate the e-mail address" to see where it checks the e-mail address against the {users} table in the database. If it finds the e-mail address just entered for an account, it gives you the error message you see. You could probably just comment those 2 lines (db_num_rows(...)) and form_set_error(...) out and it would then allow re-use. That would be my guess, anyway.

tjandt’s picture

Chris,

Thanks for the response! Though I would classify myself as a complete hack when it comes to PHP coding, I don't mind getting in there and trying stuff out to see if it works. I'll fire up the old PHP editor tonight and look for those functions in the user.module. Naturally, I'll be sure to back up the file first so after I screw it up, I can roll back to a working version :)

Tim

bigbman’s picture

Did this work? Any chance we can see an example or upgrade where this is a setting for user profiles?

Uersu’s picture

I have tried out the code change in the user.module as instructed above and it does work. I have up to now not seen any undesired drawbacks. Thanks for the instructions.

It would be good if people that also need this feature could indicate this here. It would be easy to make this a feature of the user registration with an easy radiobutton in the admin user page.

Magicbeanz’s picture

Here's the code for validating the email:

// Validate the e-mail address:
if ($error = user_validate_mail($edit['mail'])) {
form_set_error('mail', $error);
}
else if (db_num_rows(db_query("SELECT uid FROM {users} WHERE uid != %d AND LOWER(mail) = LOWER('%s')", $uid, $edit['mail'])) > 0) {
form_set_error('mail', t('The e-mail address %email is already taken.', array('%email' => theme('placeholder', $edit['mail']))));
}
else if (drupal_is_denied('mail', $edit['mail'])) {
form_set_error('mail', t('The e-mail address %email has been denied access.', array('%email' => theme('placeholder', $edit['mail']))));
}

Can someone show me how to comment out the proper parts, please?

Uersu’s picture

In the code below you can see which lines I commented out a couple of lines with /* */

// Validate the e-mail address:
if ($error = user_validate_mail($edit['mail'])) {
form_set_error('mail', $error);
}
/* ubuob 11.11.06: commented code out to allow multiple accounts with same email address
else if (db_num_rows(db_query("SELECT uid FROM {users} WHERE uid != %d AND LOWER(mail) = LOWER('%s')", $uid, $edit['mail'])) > 0) {
form_set_error('mail', t('The e-mail address %email is already taken.', array('%email' => theme('placeholder', $edit['mail']))));
}
end of commented out code
*/
else if (drupal_is_denied('mail', $edit['mail'])) {
form_set_error('mail', t('The e-mail address %email has been denied access.', array('%email' => theme('placeholder', $edit['mail']))));
}

coachellen’s picture

Another option would be to change the error message instead of commenting it out.

You could change 'The e-mail address %email is already taken.' to 'The e-mail address %email is already taken. If you are currently sharing an email account with another user, we recommend obtaining a free email account from [insert your favorite free email provider here].'

I'm fairly new to Drupal and haven't delved much into the code yet, but I'm wondering why all the text is hard-coded instead of in a language file?

thrice’s picture

All text in drupal code is passed through the t() function to translate it:

http://api.drupal.org/api/5/function/t

Translation strings are actually stored in the database.

thrice’s picture

Put me down as needing this hack. I actually did it a long time ago for a Drupal 4.6 application, and need it again now. Shame there's still no option in 5.1 for allowing this, but at least no one is seeing any problem when bypassing the duplicate email check.

joe.murray’s picture

+1 for making this a configurable option. Some of my clients have users that share an email in a household, but need to be kept separate because of their different volunteer roles and activities.

Joe Murray

Joe

Anonymous’s picture

This would be good for testing, too.
I like to set up a site with me as admin and as 'ordinary' user(s), to try out different themes, group modules and so on.

rjl’s picture

Not to be a ditto head, but ditto, I really could have used this option on a site, I just didn't want to hack into a core module.

Raymondo’s picture

Was looking up how to do this and found this thread. Put me down as a ditto. Actually, there are some funny little quirks in drupal. The one that really gets me is the hard-wired uid=1 stuff.
Thanks for posting this.

dude4linux’s picture

Add my name to the list requesting this as an option for core. In my case I want to create a drupal account for every member of our church with a user profile, picture, etc. It is important to keep individuals separate because they may have different interests, volunteer for different activities, etc. On the other hand, many couples/families share a single e-mail address, so the restriction of a unique mail address is a significant limitation of drupal's capability. I can't think of any reason for that restriction as long as the userid is unique. It would be nice, however, to have the ability to detect when multiple copies of the same message are sent to an address and suppress the duplicates.

Information is free, knowledge is acquired, but wisdom is earned.

analogious’s picture

We use drupal to register dentists and pharmacy organisations and often employees share the company email.

chuckienorton’s picture

Same here. Was hoping it would be something simple I was missing.

citizenkate’s picture

I need one of there too.

pnc999’s picture

Just to add my voice to the request for this access. We have a site where family members could potentially share the same email address, so allowing multiple users to have the same email is a good thing.

thetrickyt’s picture

Ok guys, here's something I've done to solve this problem - without any hacks to Drupal core (avoid hacks to Drupal core - they create a maintenance headache for you).

It's a little module I've written that allows you to use shared emails. Beware of using this module. Why? Because although this module works, it has potential to impact on other modules that assume each user has a unique email address (these include Simple News and Paypal Subscription which will still work but not quite as intended).

So here goes: You need to create a directory called 'sharedmail' under your modules directory and create 3 files with the following code in them.

The first file is 'sharedmail.module' :

<?php

/*
 * Created on 30/06/2007
 * 
 * This module overrides the 'user' module's validation that 
 * prevents the same email address being used by more than one user
 * 
 * All this module does is modify the email address before it is validated by the user module.
 * Because it only changes the edit value rather than the form value, the validation will pass
 * but the original unchanged email is still stored properly.
 * 
 * Works for both registration and account updates.
 * 
 * Displays a warning to the user that they are using a shared email.
 */

/**
* Implementation of hook_user().
* 
*/
function sharedmail_user($type, & $edit, & $user, $category= NULL) {

    $mail= $edit['mail'];

    if ($type == 'validate' && !user_validate_mail($mail)) {
        $edit['mail']= 'sharedmail_' . $mail;

        drupal_set_message(t('WARNING: The email address you are using (%mail) has already been registered on this site by another user. ' .
        'You should be aware that personal information such as password resets will be sent to this address. ' .
        'We strongly recommend changing your registered address to a different email address. ' .
        'You can do this at any time from your account page when you login.', array (
            '%mail' => $mail
        )));
    }

}

The second file is called sharedmail.info:

; $Id: sharedmail.info,v 0.3 2007/07/02 20:55:33 teamtastic Exp $
name = SharedMail
description = Lets the same email address be used by more than one user.
package = Other
version = VERSION

; version
version = "5.1"
project = "drupal"

And lastly sharedmail.intsall :

<?php
// $Id: sharedmail.install,v 0.3 2007/07/06 16:53:41 teamtastic Exp $

/**
 *
 * @file Provides install, updated, and uninstall functions for sharedmail.
 * 
 */

 
/**
 * Implementation of hook_install().
 */
function sharedmail_install() { 
  db_query("UPDATE {system} SET weight = -99 WHERE name = 'sharedmail'");
}

Once you've created these files with this content you can just enable the module as any other.

Cheers.

WorldFallz’s picture

yep, works great and allows me to remove my hack to the core. Definitely should be in core for v6 and if not a contrib module. thanks again.

ggevalt’s picture

Thanks for this. I was tired of updating the "hack" every time I updated. Fact is, I often forgot about it until some desperate user contacted me with the problem that they could not register new users...

Our need is great. We have a site for students and, believe it or not, we have quite a few students up in Vermont who do not have email accounts or, even, computers. So teachers often sign students up with their own emails so as to get our communications....

This would, indeed, be a handy feature in 6.0

cheers
g

geoff gevalt
http://www.youngwritersproject.org

jbomb’s picture

is this available in the modules section?

aufumy’s picture

I am willing to be a maintainer / co-maintainer for this module, it is rather simple, but useful.

I prefer going through the drupal issue queue, etc,

Made a minor change. Currently it sets the same message irregardless of the email address whether unique or not, fixed so that it only displays when another user has the same email.

pivica’s picture

+1 vote for creating drupal module - this is very useful option.

thanks

aufumy’s picture

peterx’s picture

Excellent for Drupal 5. Now we can all bug you for a Drupal 6 version. Like the kids in the back seat: Are we there yet?

petermoulding.com/web_architect

drewvancamp’s picture

I think this would be a great module, but as mentioned by another comment here, it might need to additionally compensate for the "Lost your password?" features by requiring a variation in password recovery method, for example by looking up users only by username & no longer by email address, or by allowing a user to select from a list of usernames after inputing the associated email address, etc.

I've never worked on a module before, but if I can be of any assistance, please contact me.

Thanks! (:

jbomb’s picture

This module will break the "forgot your password" link... That is to say, if a user has multiple accounts under the same email address and they request a "new password link" the link will only work with the account that they registered first.

Make sense?

phl3tch’s picture

I've made a few modifications to the module file so it will work with Drupal 6. It would be nice if this were an actual module instead of a little pile of code in a message thread. I don't quite know how to go about making that happen, but who knows, maybe I'll look into it.

Note that I changed the warning to the user -- the long scary warning in the original was a bit severe for my purposes.


<?php

/*
* Created on 30/06/2007
* Updated 26/07/2008
*
* This module overrides the 'user' module's validation that
* prevents the same email address being used by more than one user
*
* All this module does is modify the email address before it is validated by the user module.
* Because it only changes the edit value rather than the form value, the validation will pass
* but the original unchanged email is still stored properly.
*
* Works for both registration and account updates.
*
* Displays a warning to the user that they are using a shared email.
*/

/**
* Implementation of hook_user().
*
*/
function sharedmail_user($type, & $edit, & $user, $category= NULL) {
    $mail = $edit['mail'];

    if ($type == 'validate' && !user_validate_mail($mail)) {
        $edit['mail'] = 'sharedmail_' . $mail;
        drupal_set_message(t('NOTE: The email address you are using (%mail) is already registered to another user. ', array ('%mail' => $mail)));
    } else if (($type == 'submit' || $type == 'update') && strpos($mail, 'sharedmail_') == 0) {
        $edit['mail'] = str_replace('sharedmail_', '', $mail);
    }
}

rafaeldwan’s picture

doesn't work for me using 6.3

tried changing the "version" on the .info file to 6.3, but that didn't work

this would be very nice in core, especially for testing purposes!

-Rafael

peterx’s picture

My 6.4 version:
I changed the name to email_share so it would appear next to the other email related modules.
There is no option to override the current duplication check so I added code to create a new module hook:

/modules/user/user.modules:
Change the following code, the middle line, to use a function.

  // Validate the e-mail address:
  if ($error = user_validate_mail($edit['mail'])) {
    form_set_error('mail', $error);
  }
  else if (_user_email_duplicate_check($uid, $edit['mail'])) {
    form_set_error('mail', t('The e-mail address %email is already registered. <a href="@password">Have you forgotten your password?</a>', array('%email' => $edit['mail'], '@password' => url('user/password'))));
  }
  else if (drupal_is_denied('mail', $edit['mail'])) {
    form_set_error('mail', t('The e-mail address %email has been denied access.', array('%email' => $edit['mail'])));
  }

Add the function and include a check for a module hook. If any module has the hook, do not use internal validation. If any external validation returns true, stop and return the duplication error message.

function _user_email_duplicate_check($uid, $email_address)
	{
	$external_validation_found = false;
	foreach(module_list() as $module_name)
		{
		if(module_hook($module_name, 'email_duplicate_check'))
			{
			$external_validation_found = true;
			// Will this module complain about duplication?
			if(module_invoke($module_name, 'email_duplicate_check', $uid, $email_address))
				{
				return true;
				}
			}
		}
	if(!$external_validation_found
	and db_result(db_query("SELECT COUNT(*) FROM {users} WHERE uid != %d AND LOWER(mail) = LOWER('%s')", $uid, $edit['mail'])) > 0)
		{
		return true;
		}
	return false;
	}

/sites/all/modules/email_share/email_share.info:

name = Email Share
description = Let users share one email address
package = Email
core = 6.x
version = "6.x-0.1"

/sites/all/modules/email_share/email_share.module:

/*
20080917 PeterMoulding.com
Allowing Multiple Accounts from the Same E-Mail Address? http://drupal.org/node/15578
This module overrides the 'user' module's validation that prevents the same email address
being used by more than one user

All this module does is modify the email address before it is validated by the user module.
Because it only changes the edit value rather than the form value, the validation will pass
but the original unchanged email is still stored properly.

Works for both registration and account updates.

Displays a warning to the user that they are using a shared email.
*/

/**
* Implementation of hook_user().
*
*/
function email_share_user($type, & $edit, & $user, $category= NULL)
	{
	$address_prefix = 'email_share_';
	$mail = $edit['mail'];
	if($type == 'register')
		{
		}
	elseif($type == 'load')
		{
		}
	elseif($type == 'validate')
		{
		$edit['mail'] = $address_prefix . $mail;
		drupal_set_message(t('NOTE: The email address you are using (%mail) is already registered to another user. ', array ('%mail' => $mail)));
		}
	else if(($type == 'insert' or $type == 'update') and substr($mail, 0, strlen($address_prefix)) == $address_prefix)
		{
		$edit['mail'] = substr($mail, strlen($address_prefix));
		}
	}

function email_share_email_duplicate_check($uid, $email_address)
	{
	return false;
	}

This forum does not allow attachments so I bundled the code into: http://phpaustralia.com/email_share.7z
(7zip has the highest compression, is open, and is at http://www.7-zip.org/)
For those who do not yet enjoy 7zip: http://phpaustralia.com/email_share.zip

petermoulding.com/web_architect

peterx’s picture

Forget the printed code. The 7zip and zip files now contain a modified user.module and user.admin.inc. The user.admin.inc mod contains an administration option to allow duplicate email addresses and the user.module bypasses the duplication check when the admin option is set.

The hook_user insert occurs after the user is inserted. You can add new fields during insert but not change exsisting fields.

You could convert the changes to a patch and submit the change for the user module. Every time I create a patch for an open source project, the maintainer wants the patch in a different format and in a format not produced by any of the patch creation addons for the editors I use.

I tested the change on only one site and have not tested the reply to the confirmation email.

petermoulding.com/web_architect

muhleder’s picture

This is a great little module, not sure what it's going to break :) but I'm working on a site where we have to let users log in who don't have email addresses. I've added a little form_alter code to remove the requirement for an email address on the user register and user edit pages. The original code means that the blank emails are not seen as duplicates.

Here's the code, which goes in the sharedmail.module file.


/**
* Implementation of hook_form_alter().
* Override the 'required' setting for email addresses on user edit and registration forms.
*
*/
function sharedmail_form_alter($form_id, &$form) { 
  // Will get called for every form Drupal builds; use an if statement 
  // to respond only to the user register block and user ediy forms.
  // If you need to target any other forms you can inspect the form's html to find the id.
  // If the form's html css id is 'user-somestring', then the $form_id here will be 'user_somestring'
  if ($form_id == 'user_register') { 			
    $form['mail']['#required'] = FALSE;
  }
  if ($form_id == 'user_edit') { 			
    $form['account']['mail']['#required'] = FALSE;
  }
  //Uncomment one of the following lines to find the path through the $form array to the #required setting.
  //dprint_r($form); //Use this if you have the devel module installed. Makes the array easier to read.
  //print_r($form);
} 

Thanks to the Pakt book for the form alter code.

sbaptista’s picture

Worked great

sauravgr8’s picture

// Validate the e-mail address:
if ($error = user_validate_mail($edit['mail'])) {
form_set_error('mail', $error);
}
else if (db_num_rows(db_query("SELECT uid FROM {users} WHERE uid != %d AND LOWER(mail) = LOWER('%s')", $uid, $edit['mail'])) > 0) {
form_set_error('mail', t('The e-mail address %email is already taken.', array('%email' => theme('placeholder', $edit['mail']))));
}
else if (drupal_is_denied('mail', $edit['mail'])) {
form_set_error('mail', t('The e-mail address %email has been denied access.', array('%email' => theme('placeholder', $edit['mail']))));

This is the email validation module which has to be modified to have an access of multiple account from the same e-mail.

  • .
  • Orangefox Web Developers’s picture

    This hack worked for me glad I done a search before coding myself saved alot of time, A* Recommended.

    ------------------------------------
    L Morris || www.orangefox.co.uk

    ceaker’s picture

    I ended up here after googling for a solution to the same problem. I am working on a site for a community where there could be households that need separate logins but normally share an email address.

    However, it would be nice to hear from someone that has tried the following scenario report back here what they found...

    1. Create a user with admin rights.
    2. Create a second non-admin user that shares the same email as the admin user.
    3. While logged in as the non-admin user, change the configured email address.
    4. Check the email address of the admin user. Did it get changed when the non-admin user changed theirs?

    If the answer in step 4 is yes, then we have a security hole. There's nothing to stop the non-admin user from requesting a password reset for the admin user, which would at this point be sent to their email address.

    Has anyone checked this?

    Thanks.

    WorldFallz’s picture

    Yes, there is a security hole-- but not with the scenario you describe. The email addresses, though the same, are stored separately for each user--- changing one does not change the other. All this module does, is subvert the uniqueness check.

    The security hole is that if the non-admin user clicks on "request new password" and follows the process, they will be logged in and led to edit the admin's account page (at least that's what happened in my case, i'm not sure how it's picking which account to edit: alpha, user id, etc.) and a non-admin user can lockout the admin.

    IMO under no circumstances (free email accounts are too easy to get) should an admin account share an email with any other account. There's all sorts of issues with this-- apart from the password reset one. One that immediately pops to mind is that while I, as a registered user, may want to white-list a site administrator I certainly DO NOT want to white list his/her entire family. AFAIC, it borders on dishonesty. Not to mention how furious i'll be when I'm spammed from the lastest address book virus because junior was surfing warez sites with his father's admin email account.

    However, even if the admin email is not shared, it still provides the ability of one user to lockout another-- also unacceptable. The sole reason I haven't submitted this little gem to CVS is that I can't think of a good way to avoid this. any ideas would be welcome....

    ===
    "Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime."
    -- Lao Tzu
    "God helps those who help themselves." -- Benjamin Franklin
    "Search is your best friend." -- Worldfallz

    Athaclena’s picture

    A few small and maybe easy changes to make would be:
    a. enable changing the message it displays
    b. access control - which roles are allowed to have multiple users per email

    Also this should be submitted to the modules here and in drupalmodules.com .

    I'm afraid I don't have time to do it myself :-(

    Athaclena’s picture

    I've written this which sends out an email to each user using the same email... It needs to override the submit of user_pass form in user.module (and is mostly copied from there). My code is probably ugly but I think it's working... at least now that I've changed some problems.
    I believe this actually won't work with the rest of sharedmail since this needs to be loaded after user.module while now it needs to run before. Maybe the validation of email addresses when registering should be overridden so everything works together... I just don't understand the forms API so I can't!

    function sharedmail_form_alter($form_id, &$form)
    {
      if ($form_id == "user_pass")
          unset($form['#submit']);
         $form['#submit'] = array('sharedmail_submit' => array());
    }
    
    function _sharedmail_submit($form_id, $form_values)
    {
      global $base_url;
      $name = $form_values['name'];
      if (check_multiple($name))
      {
        $accounts = db_query("SELECT * FROM {users} WHERE LOWER(mail) = LOWER('%s')", $name); 
        $from = variable_get('site_mail', ini_get('sendmail_from'));
    
      while ($account = db_fetch_object($accounts)) 
      {
      // Mail one time login URL and instructions.
        $variables = array('!username' => $account->name, '!site' => variable_get('site_name', 'Drupal'), '!login_url' => user_pass_reset_url($account), '!uri' => $base_url, '!uri_brief' => substr($base_url, strlen('http://')), '!mailto' => $account->mail, '!date' => format_date(time()), '!login_uri' => url('user', NULL, NULL, TRUE), '!edit_uri' => url('user/'. $account->uid .'/edit', NULL, NULL, TRUE));
        $subject = _user_mail_text('pass_subject', $variables);
        $body = _user_mail_text('pass_body', $variables);
        $mail_success = drupal_mail('user-pass', $account->mail, $subject, $body, $from);
    
        if ($mail_success) 
        {
          watchdog('user', t('Password reset instructions mailed to %name at %email.', array('%name' => $account->name, '%email' => $account->mail)));
          drupal_set_message(t('Password reset instructions mailed to %name at %email.', array('%name' => $account->name, '%email' => $account->mail)));
        }
        else 
        {
          watchdog('user', t('Error mailing password reset instructions to %name at %email.', array('%name' => $account->name, '%email' => $account->mail)), WATCHDOG_ERROR);
          drupal_set_message(t('Unable to send mail for %s. Please contact the site admin.', $account->name));
        }
      }
      }
      else
      {  
         $account = $form_values['account'];
         $from = variable_get('site_mail', ini_get('sendmail_from'));
    
    //    Mail one time login URL and instructions.
          $variables = array('!username' => $account->name, '!site' => variable_get('site_name', 'Drupal'), '!login_url' => user_pass_reset_url($account), '!uri' => $base_url, '!uri_brief' => substr($base_url, strlen('http://')), '!mailto' => $account->mail, '!date' => format_date(time()), '!login_uri' => url('user', NULL, NULL, TRUE), '!edit_uri' => url('user/'. $account->uid .'/edit', NULL, NULL, TRUE));
          $subject = _user_mail_text('pass_subject', $variables);
          $body = _user_mail_text('pass_body', $variables);
          $mail_success = drupal_mail('user-pass', $account->mail, $subject, $body, $from);
    
          if ($mail_success) {
            watchdog('user', t('Password reset instructions mailed to %name at %email.', array('%name' => $account->name, '%email' => $account->mail)));
            drupal_set_message(t('Further instructions have been sent to your e-mail address.'));
         }
         else {
            watchdog('user', t('Error mailing password reset instructions to %name at %email.', array('%name' => $account->name, '%email' => $account->mail)), WATCHDOG_ERROR);
            drupal_set_message(t('Unable to send mail. Please contact the site admin.'));
         }
      }
        return 'user';
    }
    
    function _check_multiple($email)
    {
      $query = "SELECT uid FROM {users} WHERE LOWER(mail) = LOWER('%s')"; 
      $res = db_num_rows(db_query($query, $email)); 
      if ($res >1)
        return TRUE;
      else
        return FALSE;
    }
    jgrossmcs’s picture

    I'm primarily an infrastructure / platform geek and not a coder, so I'm looking at it from a slightly different angle. Still will require some cleanup code, but I bet ANY of you guys can toss that together quick....

    First, during your "Accout Creation" process you use dummy emails, even something as simple as a Sendmail Process on your local server so that everybody GETS a new email @server. But people don't really see this happening as you can modify the Account Creation Form to auto generate this field. Also, you have a field in the Account Create Form that captures their "Real Address". This way, you can have some code in the create form or as a secondary function that then inserts an autoforward script into the sendmail server for that particular user. Heck, you could even just have the script add a forwarder to the Sendmail Routing table if you wanted and then you'd never even really have a piece of email ever sit on your server.

    This gets you out of the "unique emails" issue without underlying code changes - because there will be modules that will use email as a primary key. Just a thought.

    Jim Gross
    Owner, Evolved Technology Strategies
    http://www.evolvedtechnology.net

    thomasmurphy’s picture

    subscribing

    peterx’s picture

    This change could be useful as a Domain Access extension where an email is unique within a domain but not across all domains. A user could then register at several related domains with one email address.

    petermoulding.com/web_architect

    aufumy’s picture

    I am wondering if the use of the openid module would satisfy this, allowing the use of a person's openid, e.g. peter.moulding.myopenid.com for multiple sites.

    Or if the home site is setup as an openid provider, logging in to other sites as 'myopenidsite.com/user/3'

    Thanks
    Audrey

    -Anti-’s picture

    Hey, I'm so glad there is a thread with lots of people talking about this - I thought I was alone.

    In education, it is imperative that the pupils of a school are not forced to have or use an email address. I think for catering to this type of web community, like clubs, workplaces, schools, etc, drupal should have an option not to require email authentication at all (ie. leaving it blank), and have some mechanism for informing email-related modules that the user hasn't supplied one so that they can fail gracefully, instead of just assuming everyone has entered a working email address.

    As it is, I'm going to have to tell pupils at my school to enter [login name]@noemail.ourdomain.net, blackhole all mail to/from that subdomain, and turn off the personal contact forms. That is so messy and clunky. Not exactly 'community plumbing' is it, especially when there is not even an internal messaging system for D6!

    Keep talking about this! Many institutions would love this functionality for D7.
    Has anyone put in a request yet?

    peterx’s picture

    You could use [login name]@example.com because example.com does not exist. See RFC 2606, Section 3.

    Compulsory email addresses are used for self registration. In your controlled environment, a common approach is to have a supervisor create users. You could created their login as part of their enrollment.

    petermoulding.com/web_architect

    -Anti-’s picture

    Thanks for your reply.

    > You could use [login name]@example.com because example.com does not exist

    It's better to use a sub of our domain because then I have control over how it is black-holed.

    > In your controlled environment, a common approach is to have a supervisor create users

    I don't want to have to create 700 accounts and then physically hand out the passwords for them on slips of paper, especially if only a quarter of them will regularly use the website. I'll moderate the account creation, checking they've entered the correct email address and name format, but I'm not going to spend two weekends creating accounts which may never be used!

    The main point is that Drupal relies far too much on email communication, rather than alternative methods.
    If a messaging module ever does get created for D6, it will still not solve the problem that drupal requires and assumes that all users have a working (and regularly used) email address.

    Cheers.

    WorldFallz’s picture

    The main point is that Drupal relies far too much on email communication, rather than alternative methods.

    I respectfully disagree. Sometimes when one is buried deep into a somewhat non-standard use case it's hard to see the forest for the particular tree one is standing in. Email is the way of the world in 90% of the use cases and as such, core is not likely to address this.

    Drupal core is architected with the philosophy of being as generic as possible for the majority of use cases while preserving the ability of contributed modules to be able to fill the gaps. This is such a gap and seems to be completely doable with a contrib. The only reason I haven't packaged up my solution into a module is I haven't had time to sort out what the alternative process should be for requesting password resets in a production environment when emails are shared. And honestly, since I only use this for testing purposes, it's not likely to make it any higher on my todo list any time soon.

    In any case, this is definitely the realm of contrib imo.

    ===
    "Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime."
    -- Lao Tzu
    "God helps those who help themselves." -- Benjamin Franklin
    "Search is your best friend." -- Worldfallz

    -Anti-’s picture

    You know a shed lot more about it than me, but I'd suggest that all other modules in existence globally assume that every user has an email. Now if someone creates a module which lets users omit the email field, won't this simply break any module which currently utilises the user's email in some fashion? Wouldn't the only way to manage email omission be in core, so that module developers could then make their modules check if an email is present, and handle it gracefully if it is not?

    > Sometimes when one is buried deep into a somewhat non-standard use
    > case it's hard to see the forest for the particular tree one is standing in

    Education and business intranets are huge areas that drupal has not really managed to tap into yet. If drupal overcame issues like this email one, these areas would no doubt *become* part of the drupal 'standard use'.

    WorldFallz’s picture

    I can't speak to the educational sector, but my main drupal sites are corporate intranets-- where everyone has an email address. Even temp and contract workers have email addresses and sharing email addresses is a huge security issue.

    have you been over to the educational group at groups.drupal.org? Maybe some of those folks have figured out an answer to this quandary.

    ===
    "Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime."
    -- Lao Tzu
    "God helps those who help themselves." -- Benjamin Franklin
    "Search is your best friend." -- Worldfallz

    -Anti-’s picture

    > Even temp and contract workers have email addresses and sharing email addresses is a huge security issue

    I agree... sharing an email address is silly; I've never even heard of such a ludicrous thing. Either you use email and have one or you don't use it and don't have one. The only reason several people would access to one email address is in a departmental situation, and they should have a ticketing system in place for that.

    What I think needs to happen is that a user can have a drupal account without having an email address at all. In club/school situations, there are other ways for admin to communicate with users:

    - phone them
    - see them in person
    - write to them
    - sms
    - skype
    - website PM system (the most sensible option, but also sadly lacking in D6)

    If an admin of a website chooses to switch off compulsory email registration, it is blatantly obvious that they choose to do so because they will rely on another method of communication. So I don't see why we have to flip backwards over this stupid 'reset password' issue - if resetting the password is the only reason email is compulsory then drupal is even more narrow-minded than I thought.

    WorldFallz’s picture

    Actually, I have no clue why email is compulsory, lol. Without knowing the history of that decision, I can only speculate, but I agree it doesn't seem necessary.

    However, I do think it necessary to provide another method of password reset for when the "no email required" option is enabled. It's simply unacceptable to have no method for resetting the login credentials. It's poor design on so many levels i can't imagine it even getting considered for core. Besides, having been in usability for many years I can't even tell you how many times i was shocked at how not obvious the "blatantly obvious" can be.

    Have you browsed the forums much lately? Its almost frightening how many times i see the "omg i'm locked outta my site" posts. These are the same people you want to manage the password reset procedure on their own? lol. And as drupal get more popular, the problem will only get worse as less and less technically savy people find it.

    I've seen it done without requiring email so I know it's possible and it's not that complicated-- it's just a matter of someone caring enough to code it up. Feature requests tend to proceed a lot faster when accompanied by patches.

    ===
    "Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime."
    -- Lao Tzu
    "God helps those who help themselves." -- Benjamin Franklin
    "Search is your best friend." -- Worldfallz

    -Anti-’s picture

    > However, I do think it necessary to provide another method
    > of password reset for when the "no email required" option
    > is enabled

    You're right in so many wise ways. No argument.

    But worrying about password resetting will mean that this feature will simply not be implemented. So you can understand my stance of not caring about people who don't read the warning and/or understand the consequences of disabling compulsory email at registration. I mean, you'd only want to disable email registration if you were running a real-life club website for people you know and meet, not a website for anonymous masses. In the future, there might be an email alternative which everyone uses, but for now all that clubs/schools/businesses need is for compulsory email to be turned off.

    WorldFallz’s picture

    But worrying about password resetting will mean that this feature will simply not be implemented

    But that's the point i think I'm trying to make-- i'd hate to see someone go down this road and put some work in a patch for core that gets rejected out of hand for this reason, that's all. But i'm no core guru-- maybe it would be considered without it... this is all just a big "imho", lol.

    ===
    "Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime."
    -- Lao Tzu
    "God helps those who help themselves." -- Benjamin Franklin
    "Search is your best friend." -- Worldfallz

    linksunten’s picture

    We implemented some of -Antis- ideas:

    http://drupal.org/node/353953#comment-1198355

    And yes, we know that it is a problem if users cannot change their password. But we have a simple solution: Make a new account and forget about the old. Namen sind Schall und Rauch... ;-)

    IMC linksunten

    peterx’s picture

    Drupal has the concept of workflow implemented for creating content and comments. They create. Nothing appears until you edit and confirm. The registration equivalent might be to use your email address for the confirmation address. As soon as they register, the email goes to you. You check their registration and approve it.

    Another step might be to extract the student list as a CSV file and input to the database direct.
    Id First Second
    123 Eldrick Woods
    124 Sarah Palin
    125 Barack Obama
    There is a need for bulk registration, I add it to non Drupal sites and will add it to my next Drupal site.

    I also extract the lists as SQL files and import direct using phpMyAdmin, something you might consider if the 700 students are listed in an existing database.

    Something to consider long term: Use the multiple site facility and Domain Access to run several sites from one database sharing the user list. You can then have my.example.com, moodle.example.com, grumpyoldadministration.example.com, timesheets.teachers.example.com, singles.teachers.example.com, and detention.example.com all running off the same list. You can gradually switch your office functions across to the same system. There are modules to handle mass mailing and other functions of interest to community oriented organisations. Your Web site can become the center of your business with secure remote access for people working from home or other locations.

    With a Web based computer system, you have some protection against unforeseen events. When hurricane Xyz destroys your school, your server is safe in a well protected datacentre and you can carry on with classes in tents.

    petermoulding.com/web_architect

    muhleder’s picture

    There is the sharedmail module above which can remove the need for email addresses, unique or otherwise. If you want to add a fallback for emails that are sent to users without email addresses, you might be able to hook into that action and divert to an administrator email if none present. Or have a cron script which will fill empty user email fields with your fallback email.

    peterx’s picture

    The Drupal 6 user.module has the email checks at a point that cannot be easily overridden by an external check. I resorted to modifying user.module. We need an extra hook in user.module to connect to modules with alternatives to email verification. The hook could be called by other parts of the system requiring an email alternative. You could cover all the varied requirements with one change.

    An alternative is to continue modifying user.module with administrative settings to allow other combinations of email. You would then need a function to supply the settings to other modules.

    Allow shared email addresses
    Allow registration without email address
    Allow non standard format email addresses for internal systems
    Allow spam addresses [hotmail, AOL, ...]

    When we get into blacklisting email addresses and similar management issues, we need an external module to stop user.module bloat.

    petermoulding.com/web_architect

    WorldFallz’s picture

    That's sounds like a viable solution that might get considered for core, but there is still the issue of password reset procedures for each of the scenarios. probably worth posting a feature request though.

    ===
    "Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime."
    -- Lao Tzu
    "God helps those who help themselves." -- Benjamin Franklin
    "Search is your best friend." -- Worldfallz

    -Anti-’s picture

    > but there is still the issue of password reset procedures for each of the scenarios

    Why? If you're allowing users to register without email, it means that you are not
    primarily using email for communication in your club/school/organisation. So you'll have
    another way of communicating with the users for admin purposes.

    In other words, don't complicate this: if an admin chooses to turn off email registration
    then drupal doesn't have to provide an alternative - it's up to the organisation how they
    deal with account administration (Eg. physically seeing a user, an PM system, phone/sms,
    etc). All drupal has to do is ensure that modules don't assume there is an email address
    and fail gracefully in those instances.

    WorldFallz’s picture

    I think we'll just have to agree to disagree here. There has to be a method of password reset in all scenarios-- to provide a login credentials and not provide a means to reset them when the user has forgotten them and/or locked themselves out is a poor usability design and an administrative nightmare for anything more then a few users.

    It's easy to say "well if you choose a certain option then you have to be responsible for the password reset procedure" but my mind reels at the amount of forum posts that will result from users that paid those instructions no heed. They can't even be bothered to read the INSTALL.txt file included in every drupal tarball-- never mind this.

    There are password reset methods that do no involve email-- lately it seems the best practice is to use multiple levels of security questions. It's just going to take some effort to work out the details.

    In any case, i don't see this feature being implemented in core without a password reset feature. Moreover, this thread, as interesting as it is, isn't going to result in any changes to core either. Until someone picks up the mantle, creates a feature request, and starts to drive it with some actual code, this is just an intellectual exercise.

    ===
    "Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime."
    -- Lao Tzu
    "God helps those who help themselves." -- Benjamin Franklin
    "Search is your best friend." -- Worldfallz

    peterx’s picture

    I agree that the password reset procedure needs some thought. We need to identify the password reset process and define a hook for handling the password reset. The one change request can ask for the two hooks, registration and reset, or one hook to handle both.

    My favourite reset process: You connect the reset email through Web services to a pizza delivery Web site. They write the new password on a pizza in hot red chilli sauce. Your password arrives in 20 minutes. After you read the password, you have to destroy the message by eating it.

    petermoulding.com/web_architect

    peterx’s picture

    Ok, I did it: http://drupal.org/node/313225

    A request for a change in the core user module. While it may not be a heart transplant, it is equivalent to a heart valve repair. Arnold Schwarzenegger, famous for his roles in Hercules in New York and Stay Hungry, survived a similar operation without his Web site going down. Surely we can talk the core code cutters into creating his cute change.

    One way to influence the people who drill down to the core is to add constructive ideas and names to the change request. Add your name and need to http://drupal.org/node/313225 to get the core change spinning.

    Request either shared email or no email or external processing through a user selected module to cover SMS and other options. Anything outside of that will delay the change.

    For the movie challenged, Arnie made his gym movie 7 months before some other guy released Rocky. Rocky succeeded only because it had better music.

    petermoulding.com/web_architect

    muhleder’s picture

    I don't think it needs all that code. The original sharedmail module in this thread seems to work ok with the v6 mod above if you set the weight of the module to be -99 in the system table. Not sure why the .install file isn't doing that, doesn't seem to be getting called when I install it.

    newbuntu’s picture

    The original sharedmail module in this thread seems to work ok with the v6 mod above if you set the weight of the module to be -99 in the system table.

    which v6 mod are you referring to? Can you point to the comment#?

    I had to modify the module so it installs and runs on 6.x. But the result is incorrect: the new user gets an email like: sharedemail_foo@bar.com. I wanted it to share foo@bar.com.

    I checked DB, the module weight is -99.

    radishred’s picture

    Hi there,
    I was trying out the email_share files and I am having an issue with the email address getting registered as email_share_foobar@example.com as opposed to foobar@example.com. I have changed the weight of the email_share module to -99 in the system table. Anyone else have this issue?? How do I solve it?
    Thanks in advance.

    newbuntu’s picture

    I was having exactly the same issue http://drupal.org/node/15578#comment-1127945

    In my case, I went to an "optional email" solution. I figured out a way to do it. If anyone is interested in "optional" email for registration, here is a small module that may help http://drupal.org/node/286401#comment-1128021

    Shared email at registration time has too big a security hole than I could tolerate. What if someone knows admin's email, then uses that email to register a new account?

    IMHO, shared email as a feature needs a very clear definition. It is important to define what exactly it can and CANNOT do.

    aufumy’s picture

    Knowing the admin's email does not grant another person admin privileges, even if they were to use the same email address in their profile.

    Drupal works with a unique user id that is linked to each user account. Sharing emails does not mean sharing drupal user accounts, sharing usernames or sharing passwords.

    If the person had actual access to check email with the administrators email address, then yes, they could have access to the admin's user information, however that would apply to drupal in general (without the sharedemail module), or any user login system that uses email to authenticate the user, which is all cms's I am familiar with.

    The drupal6 version of sharedemail module is out now.
    http://drupal.org/project/sharedemail

    While I am not actually using this module now, I have spent time to commit it to cvs, and will continue to maintain it. I would appreciate if there were questions, feature requests, support requests that they are done using drupal's issue and patch system.

    This forum post has lived long past its shelf-life I believe.

    lisa-o’s picture

    there is none just now

    chewitt’s picture

    I'm working on a test site, and I only have one email address. I needed to create a user account besides admin, just so I could see what the site looks like for a user with normal permissions and submit content. Not too much to ask, right?

    The workaround is that all gmail accounts with periods in it are treated equivalently (see http://gmailblog.blogspot.com/2008/03/2-hidden-ways-to-get-more-from-you...). In other words, name@gmail.com = na.me@gmail.com = n.a.m.e@gmail.com, etc. To create a new drupal account, just add or remove a period to make the email address different. D6 treats the emails as unique, but they'll all get to your inbox just the same. Other email hosts may do this as well - I don't know. [Drupal team, please don't "fix" this unless you open up another option!]

    I am learning’s picture

    Anybody who is looking for Shared Email i.e. one email id for multiple accounts can use Shared Email Module

    longhairedgit’s picture

    Hi all,
    Depending on your situation, you might just be able to use multiple email addresses of the form
    yourname+tag@blah.com

    for example if your normal email addr is blah@blah.com
    blah+drupaltestuser@blah.com
    blah+drupaladmin@blah.com

    etc.
    The part after the '+' should be ignored during the mail delivery but still makes the email look unique to drupal.

    see
    http://en.wikipedia.org/wiki/Email_address
    under 'sub-addressing'
    for more info.

    cheers

    davpas’s picture

    This depends on what email provider the person uses. Some email accounts (such as those provided by ISP's) may not allow for the plus sign hack on email account names as they consider the plus sign to be a legitimate character in an email address. So be careful about choosing to use it as the recipient may or may not receive any email sent to them.