bmun/huxley

Improve Password Reset flow

Closed this issue · 2 comments

mathildepm commented

Two things

  1. The password reset email is incredibly (almost hilariously) problematic. It only says

The password for user Jeremy_8392 has been reset to QsZktha5dV.
Thank you for using Huxley!

And the period at the end of the password is there for grammatical purposes, but ends up being included when delegates try the new password.
Step 1 is to update the email to be more clear. Take a look at the email we send when account are first created. It might be more clear to have a set up like "something something Berkeley Model UN" and then "Username: testuser // Password: cheese" etc

  1. Advisors will often click "reset password" without really thinking. This can confuse delegates if they already have their password and it gets reset without them knowing. It can also just been ineffective if the advisor has put the wrong email. Before enacting the password reset, have clicking the button make a pop up appear with details one what is about to happen. "This will send an email to with new login information. Are you sure this is the correct email? Note that school organizational emails sometimes have emails from outside parties blocked" or something like that. This should allow them to either proceed or go back.
erwang01 commented

For some reason, the emails don't seem to be sending...

I can confirm that the Hashed passwords are changing when I hit the reset password button but I am not receiving any emails. Does this have something to do with me running this as a local dev version?

  • Update 12/6/21: yeah its to do with running with default settings using DevLoggingEmailBackend which simply logs the email rather than sending the email. Not quite clear which email backend I should be using yet tho... maybe LoggingEmailBackend. The setting to change is called EMAIL_BACKEND and can currently be found in huxley/settings/main.py

@mathildepm How'd you generate your example with Jeremy_8392?

srisainachuri commented

Unfortunately, we don't have a dev email backend setup, so the only way to test the actual email is through the server stage. For the purposes of this issue, we can assume user.email_user works as intended and focus on the text sent in this function call, and the advisor sanity check before the call.