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
Hmm, five weeks and no
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?
Will require modifying the code
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.
Thanks for the reply!
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
Did this work? Any chance
Did this work? Any chance we can see an example or upgrade where this is a setting for user profiles?
Code change works
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.
Here's the code for
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?
Required code change
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']))));
}
Another option
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?
It's a translation function, not a file
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.
I need this hack
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.
+1
+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
same e-mail with multiple user IDs - would be good feature
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.
Not to be a ditto head, but
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.
Was looking up how to do
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.
Add my name to the list
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.
Excactly the same request
We use drupal to register dentists and pharmacy organisations and often employees share the company email.
I'll have the same.
Same here. Was hoping it would be something simple I was missing.
YES PLEASE!
I need one of there too.
Me Too
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.
The solution
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' :
The second file is called sharedmail.info:
And lastly sharedmail.intsall :
Once you've created these files with this content you can just enable the module as any other.
Cheers.
2nd that...
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.
Thanks and I'll 15th that...
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
geoff gevalt
http://www.youngwritersproject.org
http://www.ywpschools.net
http://geoffreygevalt.com
is this available in the
is this available in the modules section?
will take this on
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.
+1 vote for creating drupal
+1 vote for creating drupal module - this is very useful option.
thanks
Project created on drupal.org
http://drupal.org/project/sharedemail
Excellent
Excellent for Drupal 5. Now we can all bug you for a Drupal 6 version. Like the kids in the back seat:
petermoulding.com/web_architect
petermoulding.com/web_architect
Please do!
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! (:
Also worth mentioning...
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?
Update for D6
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.
doesn't work for 6.3
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
6.4
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.
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.
/sites/all/modules/email_share/email_share.info:
/sites/all/modules/email_share/email_share.module:
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
petermoulding.com/web_architect
The code is not removing email_share_
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
petermoulding.com/web_architect
Addition to remove requirement for email address
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.
Thanks to the Pakt book for the form alter code.
Thanks
Worked great
// Validate the e-mail
// 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.
It works..
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
Security hole?
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.
Yes, there is a security
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
Having installed the module here...
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 :-(
I've written some code...
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!
Not A Coder - but another way to solve this...
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
subscribing
subscribing
Email per site and Domain Access
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
petermoulding.com/web_architect
I am wondering if the use of
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
Hey, I'm so glad there is a
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?
example.com
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
petermoulding.com/web_architect
Thanks for your reply. > You
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.
The main point is that
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
You know a shed lot more
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'.
I can't speak to the
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
> Even temp and contract
> 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.
Actually, I have no clue why
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
> However, I do think it
> 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.
But worrying about password
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
no_mail module
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
Workflow
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
petermoulding.com/web_architect
There is the sharedmail
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.
Core change needed
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
petermoulding.com/web_architect
That's sounds like a viable
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
> but there is still the
> 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.
I think we'll just have to
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
Password reset procedure
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
petermoulding.com/web_architect
Cut to the core
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
petermoulding.com/web_architect
I don't think it needs all
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.
The original sharedmail
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.
Having issues with email_share_ being appended to the address
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.
I was having exactly the
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.
Knowing the admin's email
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.
reply
there is none just now
Gmail workaround
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!]
Anybody who is looking for
Anybody who is looking for Shared Email i.e. one email id for multiple accounts can use Shared Email Module
adding a tag in your email address
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
This depends on what email
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.