Feature #688

Allow the same email for two accounts

Added by Thomas Lecavelier almost 12 years ago. Updated over 3 years ago.

Status:ReopenedStart date:2008-02-18
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Accounts / authentication
Target version:-
Resolution:

Description

I think it would be better to permit two accounts to have the same mail adress. Here my arguments:

  1. I manage redmine, but not the SMTP server: I have only one email adress, no aliases, so I'd like to set the admin account and my personnal account to the same email adress.
  2. Villain users could register other users email just to avoid them to register.
  3. Spammer could try to register every email they can. When they can't, they know that they've got a valid email. Bad thing.

Related issues

Duplicated by Redmine - Feature #7599: Allow for multiple useraccounts with same email address Closed 2011-02-10

History

#1 Updated by Jean-Philippe Lang almost 12 years ago

I agree with you but I see one little problem: how to identify a user how submits a ticket via email if the address is assigned to 2 users ? (ticket submission via email will be added in the future).

#2 Updated by Thomas Lecavelier almost 12 years ago

Damn, I hadn't thought about that issue... The only way to avoid this kind of problem should be to add a user preference saying that this account can submit a ticket via email: in that case, the uniqness condition should be "email" + "can submit via mail". This could be a good solution, since people who will want to submit via email are people that don't want to login in redmine, so they barely can't want to have two accounts. Sound good?

#3 Updated by Jean-Philippe Lang over 11 years ago

Oh, I've just though about it, it would cause a big security issue in the password reminder since it asks for your email only.

I won't go into the details but if the password reminder was left as-is, anyone could be able to change anyone else password using the password reminder.
Of course, we could ask for the username in the password reminder, rather than the email, but I think it's not a good solution since you may not remember your username as well (for myself, I usually don't remember it when I have to use password reminder).

#4 Updated by Thomas Lecavelier over 11 years ago

  • Status changed from New to Closed

There's still something that annoy me, but it's now most the password reminder than the "same email for multiple accounts" thing. So I prefere close this feature request and play with the reminder later, to forge myself a global opinion.

Thank you for your points.

#5 Updated by Szabolcs Szasz about 11 years ago

  • Status changed from Closed to Reopened

(Sorry about reopening this, but I guess it's better to follow-up this than opening a new thread-of-thoughts alont these same lines.)

The unique email requirement has also annoyed me from the beginning. But Jean-Philippe's points, however, convinced me...

Well, but then my itches have shifted to this design issue: if there's already a unique identifier, which is the email, why, oh why, to maintain a seemingly completely pointless, redundant internal identifier in addition to that? (I guess the email "non-shareability" was probably discovered only after using the other ID.)

(E.g. in our system, all members have mails in the same domain, so all our user IDs are just the emails... Well, almost, because that did not work due to another restriction: on user IDs lengths, so they only have the "local part" before the @ as their IDs. Unfortunately, another unnecessary Redmine restriction (on valid chars in the IDs) also did not allow us to use the existing Drupal account IDs either... :-/ )

Why not using the (anyway required) name in all UI rendering, and why not using the (anyway required and perfectly unique) email as the internal ID?

I have just realized that this ID-ambiguity is, where that "discomfort" about the forbidden emails actually stems from. So, to really end this problem, we need to solve the underlying problem behind these non-shareable email addresses: their falsely implied apparent shareability should be removed. Using the email as the internal ID should do that.

Thanks,
Sz.

#6 Updated by Gerrit Kaiser almost 11 years ago

Why not using the (anyway required) name in all UI rendering, and why not using the (anyway required and perfectly unique) email as the internal ID?

+1 to not require a “login” for every user.

#7 Updated by Ben Blanco almost 11 years ago

Why not using the (anyway required) name in all UI rendering, and why not using the (anyway required and perfectly unique) email as the internal ID?

+1 as well!

and also:

Well, almost, because that did not work due to another restriction: on user IDs lengths

We have the same problem - we've standardized the platform so that logins are User emails. Unless Logins can be replaced by emails, it would be great if this field's max length could be increased, say to 50 chars or more (I believe current limit is 30).

#8 Updated by Ken Sands almost 11 years ago

Jean-Philippe Lang wrote:

Oh, I've just though about it, it would cause a big security issue in the password reminder since it asks for your email only.

I won't go into the details but if the password reminder was left as-is, anyone could be able to change anyone else password using the password reminder.

I don't understand how this is a problem, if i'm both the administrator and a developer, I'd like both to go to my email address, how would it allow anyone else to change my password any different to when just one account is assigned to the email address?

#9 Updated by Jean-Philippe Lang almost 11 years ago

Well, forget about it.

#10 Updated by Ken Sands almost 11 years ago

Jean-Philippe Lang wrote:

Well, forget about it.

I'll have a go at making this work in my copy, if I work out what the issue is I'll see if I can come up with a solution and a patch.

#11 Updated by Ken Sands over 9 years ago

There was no problem, it works fine. I added a field to state which user would be used for issue updates via email, besides that it's just a case of commenting out the validates_uniqueness bit. Maybe there is some deeper issue that I'm missing but for me this now works a treat, I get all the updates through destined for Admin and yet can send updates and receive specific updates as a developer all to the same email. I'm likely to be the only one with 2 accounts on one email it was simply for the admin account.

#12 Updated by Al McNicoll over 7 years ago

OK, so it's an old ticket, but on the off-chance that Ken is still using Redmine:
Would you mind sharing your patch? This multiple-email-address issue is causing innumerable headaches on a system I'm administering because each redmine user has to map 1-1 with external-system users that may share email addresses.

#13 Updated by Alberto Cennini almost 5 years ago

Even if it's an old issue, have I any chance to have a patch to solve it ?
Thanks

#14 Updated by Daniel Zabaljauregui over 3 years ago

Ken Sands wrote:

There was no problem, it works fine. I added a field to state which user would be used for issue updates via email, besides that it's just a case of commenting out the validates_uniqueness bit. Maybe there is some deeper issue that I'm missing but for me this now works a treat, I get all the updates through destined for Admin and yet can send updates and receive specific updates as a developer all to the same email. I'm likely to be the only one with 2 accounts on one email it was simply for the admin account.

I too get that this issue is quite old and lacks current activity or interest, but even so I´d greatly appreciate if Ken or somebody else could please share a patch to implement it (just the functionality that Ken mentioned). Thanks in advance!

Also available in: Atom PDF