Feature #1853

Allow login via email and/or username with settings in the ACP

Added by Dylan Myers over 2 years ago. Updated 8 months ago.

Status:ClosedStart date:12/18/2011
Priority:NormalDue date:12/21/2011
Assignee:Dylan Myers% Done:

100%

Category:Logging InEstimated time:0.50 hour
Target version:1.6.11

Description

Many users have requested this. I have a tutorial for it here:
http://community.mybb.com/thread-105870.html

However, per Staff discussion we've decided to add this to the core with an additional switch in the ACP to determine which types we'll allow.

History

#1 Updated by Dylan Myers over 2 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Applied in changeset r5733.

#2 Updated by Nathan Malcolm over 2 years ago

I think that the "Allowed Login Methods" setting should have some sort of description. Even though it might be self explanatory, some users might need it to be elaborated.

Also you should take into consideration the quick login/the login page language strings. By default they are set to "Username", but it should take into account the setting value.

"Email" and "Username or Email" language strings should added.

Also when the setting is set to "Email Only" I can only login with my username, and when the setting is set to Both Username & Email, I can only login with my email.

Also when logging in, and you enter a wrong combination, it produces the error:

You have entered an invalid username/password combination. 

Again, it should respect the setting value. I'm sure there are other places too. :)

#3 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Resolved to Feedback

Oops, shouldn't rush in the morning. :/

#4 Updated by Dylan Myers over 2 years ago

Apparently I shouldn't rush either. That change was supposed to be another WIP one, but I messed up which one I copied from the wiki when I started using the proper "Feature" tags (I also updated the wiki to match our current tag format as well). Oops.

#5 Updated by Dylan Myers over 2 years ago

Ok, I see why you're getting incorrect behaviour. In the code I used 1,2,3 and in the settings I used 0,1,2. I'll upload a fix for that when I upload the settings xml with a description added.

I hadn't thought of the lang strings before, or making them obey the setting. I'll do that as well. Thanks for the idea :)

#6 Updated by Josh Harmon over 2 years ago

I am not sure if you have noticed it, but from a quick look in the r5733 repository, the settings.xml file has a typo:
On line 564:
0=Userame Only

Should be:
0=Username Only

#7 Updated by Dylan Myers over 2 years ago

Josh Harmon wrote:

I am not sure if you have noticed it, but from a quick look in the r5733 repository, the settings.xml file has a typo:
On line 564:
0=Userame Only

Should be:
0=Username Only

Thanks, I'll correct that in the next update! :)

#8 Updated by Dylan Myers over 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5736.

#9 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Resolved to Feedback

member.php?action=login

"Username:" should obey the setting.

Also in messages.lang.php the email template for a random password contains the following:

Username: {3}
Password: {4}

The template tells the user to login with those details, but if email only is enabled then it could cause confusion. Again it should obey the setting. :)

Apart from that everything else seems to be working as expected.

#10 Updated by Dylan Myers over 2 years ago

Stop finding more work for me to do! :P

(Doing these now)

#11 Updated by Dylan Myers over 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5737.

Assuming someone grumble grumble doesn't find anymore lang strings to be updated... we should be good to go on this now ;)

#12 Updated by Chris Köcher over 2 years ago

Sorry, but I've got another one:

Whats the sense of these three lines in r5737:

$l['username'] = "Username:";
$l['username1'] = "Username:";
$l['username2'] = "Username:";

?
I think, this should be:
$l['username'] = "Username:";
$l['username1'] = "Email:";
$l['username2'] = "Username/Email:";

And:
In r5736 you've forgot to change the MyBB-version of the changed templates to 1606... ;-)

#13 Updated by Dylan Myers over 2 years ago

Chris Köcher wrote:

Sorry, but I've got another one:

Whats the sense of these three lines in r5737:

[...]
?
I think, this should be:

[...]

You are of course correct... doh! (Fixed now)

And:
In r5736 you've forgot to change the MyBB-version of the changed templates to 1606... ;-)

Hrm... I didn't even think about the versions. Still not used to template changes like that, so thanks for the reminder :)

#14 Updated by Dylan Myers over 2 years ago

Applied in changeset r5738.

#15 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Resolved to Feedback

Found an issue.

(Allowed Login Methods - Both Username & Email)

When resetting my password, the body of the new password email is blank.

#16 Updated by Dylan Myers over 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5739.

#17 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Resolved to Feedback

Sadly that fix didn't work. Confirmed that the body is blank no matter the setting value.

I've just noticed that this feature also affects the admin cp login, so the "Username:" label there should also obey the setting.

#18 Updated by Dylan Myers over 2 years ago

Nathan Malcolm wrote:

Sadly that fix didn't work. Confirmed that the body is blank no matter the setting value.

I've just noticed that this feature also affects the admin cp login, so the "Username:" label there should also obey the setting.

Curious, the way I implemented that one it shouldn't be sending a blank email at all... hmm...

#19 Updated by Dylan Myers over 2 years ago

Actually... it works just fine for me. Can anyone else confirm this as non-working?

#20 Updated by Dylan Myers over 2 years ago

Dylan Myers wrote:

Actually... it works just fine for me. Can anyone else confirm this as non-working?

Ahh, I see. It isn't the lang string I edited. Its the email to actually send the new random password. Not the one with the link to create it.
On that note however, I do have some more work to do there, since it wont accept the "email" instead of username when set to email only or both. Also the lang string for that page needs changed as well. I'm not sure why an email string I never edited would be having this issue, but I'll look into it.

#21 Updated by Dylan Myers over 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5740.

#22 Updated by Nathan Malcolm over 2 years ago

member.php?action=lostpw

On the "Lost Password Recovery Form" it says "Request Username / Password" which should also obey the setting. An easier way would be changing it to "Request Login Credentials".

member.php?action=resetpassword

"Username:" should again obey the setting.

r5740 fixed the empty email body issue. Glad that is finally working. :)

#23 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Resolved to Feedback

#24 Updated by Dylan Myers over 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5741.

Fixed, any more? :P

#25 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Resolved to Feedback

I'm afraid so. ;)

The error_no_permission() function produces a login form.

Sigh Once again, "Username:" should obey the setting.

#26 Updated by Dylan Myers over 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5742.

Hopefully thats the last of them ;)

#27 Updated by Dylan Myers over 2 years ago

  • Status changed from Resolved to Feedback

I once again forgot to change the version on the templates that I've updated. Oops. I'll do that this evening, I have company on the way over right now.

#28 Updated by Dylan Myers over 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5743.

Ok, templates now versioned. Lets hope thats everything to make this work right.

#29 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Resolved to Closed

#30 Updated by Nathan Malcolm over 2 years ago

  • Status changed from Closed to Feedback

Yet another. Sorry Dyan.

portal.php - Sidebar login

#31 Updated by Chris Köcher over 2 years ago

Not a bug, but in r5742 in inc/functions.php is some unnecessary code:

        switch($mybb->settings['username_method'])
        {
            case 0:
                $lang_username = $lang->username;
                break;
            case 1:
                $lang_username = $lang->username1;
                break;
            case 2:
                $lang_username = $lang->username2;
                break;
            default:
                $lang_username = $lang->username;
                break;
            case 0:
                $lang_username = $lang->username;
                break;
        }

The last "case 0" can be removed because its doubled...

#32 Updated by Dylan Myers over 2 years ago

Nathan Malcolm wrote:

Yet another. Sorry Dyan.

portal.php - Sidebar login

Why sorry? ;) I said lets try and find them all before we release.

Chris Köcher wrote:

Not a bug, but in r5742 in inc/functions.php is some unnecessary code:
[...]
The last "case 0" can be removed because its doubled...

Awesome, thanks for that. Not sure how it happened, but always good to not have it in there.

#33 Updated by Nathan Malcolm over 2 years ago

Dylan Myers wrote:

Nathan Malcolm wrote:

Yet another. Sorry Dyan.

portal.php - Sidebar login

Why sorry? ;) I said lets try and find them all before we release.

I hate giving the devs too much work. ;)

#34 Updated by Dylan Myers about 2 years ago

  • Status changed from Feedback to Resolved

Applied in changeset r5744.

#35 Updated by Chris Köcher about 2 years ago

Sorry, the template version again... :-P

#36 Updated by Dylan Myers about 2 years ago

Chris Köcher wrote:

Sorry, the template version again... :-P

Dammit, I'm terrible with remembering that :|

#37 Updated by Dylan Myers about 2 years ago

Applied in changeset r5745.

#38 Updated by Tom Moore about 2 years ago

  • Target version changed from 1.6.6 to 1.6.7

#39 Updated by Nathan Malcolm about 2 years ago

  • Status changed from Resolved to Closed

It looks like we've got everything. Hooray!

#40 Updated by Stefan T. 9 months ago

  • Status changed from Closed to Feedback
  • Target version changed from 1.6.7 to 1.6.11

The unlock feature in ACP still accepts only the username while the label says it accepts email addresses, too.

#41 Updated by Stefan T. 9 months ago

  • Status changed from Feedback to Resolved

Fixed in 1.6 (bcb0bc65b5) and 1.8 (5d22e6e7fb)

The commit also adds missing error messages.

#42 Updated by Jones H 8 months ago

  • Status changed from Resolved to Feedback

Except of the "$class" problem it works now

#43 Updated by Stefan T. 8 months ago

  • Status changed from Feedback to Resolved

Fixed in 1.6 (c6368ea8a4) and 1.8 (d435428da2)

#44 Updated by Jones H 8 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF