Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reset Password page has bad UI & UX (non-informative on errors, etc) #7082

Open
1 task
shaunanoordin opened this issue Apr 24, 2024 · 3 comments
Open
1 task
Assignees
Labels

Comments

@shaunanoordin
Copy link
Member

shaunanoordin commented Apr 24, 2024

UI/UX Issue Bug

The Reset Email page has several UI and UX issues.

TL;DR:

  • When you try to reset your password and encounter an error, no error message is displayed
  • When you successfully reset your password, no success message is displayed, only an immediate redirect to a login prompt.
  • You can access the password reset page while you're still logged in, in some cases.

(EDIT: updated this from a UI issue to an actual UI bug. There's an actual error in our error-catching code.)

Full Report

First, some context - there are TWO variations of the Reset Email page:

OK, now to the issues.

  • The "Initiate" version can't be accessed if the user is already logged in. ✔️ This makes sense.
    • The message you get is: "You are currently logged in. Please log out if you would like to reset your password."
  • ❔ The "Confirm" version CAN be accessed if the user is already logged in. ✖️ This isn't a breaking issue, but makes less sense.
  • ❗ If the password reset action (on the "Confirm" version) runs into errors, no error message is displayed
    Screenshot: this is what you see after 1. you open the "Confirm" page with an INVALID password reset token, 2. type in a valid password, and 3. click on "Submit". Result: NO error messages are displayed, page remains as-is, but a 422 error is displayed in the dev console.
    image
    • Tested with invalid password reset tokens, which is the most likely cause of errors.
    • This means users aren't aware when a password reset isn't successful!
    • "Invalid password" errors seem to be caught as expected.
  • ❓ If the password reset action (on the "Confirm" version) IS successful, you're immediately redirected back to the Projects page, with a login prompt. There is no success message.

Status

The lack of error messaging is the biggest problem here, as this may explain why some volunteers tell us they've "reset their password, but it still doesn't work". (Example: https://zooniverse.freshdesk.com/a/tickets/19558)

This may be affecting more users than we're aware of. Suggesting medium priority, at minimum.

@shaunanoordin
Copy link
Member Author

Oh, butts - OK, there's an actual error in our error-catching code.

In reset-password.jsx, there's this code:

auth.resetPassword({ password, confirmation, token })
  .then(() => {
    ...
  })
  .catch((error) => {
    this.setState({
      resetError: error.message
    });
  })
  .then(() => {
    ...
  });

In the .catch() block, the error we get does NOT have an error.message when, for example, we get a 422 error from the server due to an invalid password reset token. As a result, state.resetError will be undefined, so it looks like there was no error!

The error is actually a HTTP Response object, not an Error/Exception object, so the actual error message is buried in error?.body?.errors?.[0]?.message === "Reset password token is invalid"

Suggested solution:

const errorMessage = error.message || error?.body?.errors?.[0]?.message || 'Unknown error';
this.setState({
  resetError: errorMessage
});

@AeleSahithi
Copy link

@shaunanoordin, I would love to work on it. Could you please assign it to me?

@shaunanoordin
Copy link
Member Author

@AeleSahithi Sure thing! Thank you for volunteering to help with our code base, your contribution will be very welcome.

Here's my recommended approach to addressing this issue:

Step 1: try to get Panoptes-Front-End running on your machine.

  • checkpoint 1: you should be able to view the website running at https://localhost:3735
    • (see this part of the README)
    • You may see a "your connection is not private" warning. This is due to the local dev server running https instead of http. This is normal.
  • checkpoint 2: you should be able to view the website running at https://local.zooniverse.org:3735
    • this will require you to modify your hosts file to so that local.zooniverse.org points to your localhost.

    • Example of editing `hosts` file With my Macbook, I run `sudo vim /etc/hosts`. I then edit the file to include the following entries:

      127.0.0.1 localhost
      127.0.0.1 local.zooniverse.org

  • checkpoint 3: you should be able 1. register a new staging Zooniverse account, and 2. login
    • note that the localhost / local.zooniverse.org uses staging test data, which is different from live production data used on www.zooniverse.org. This is why you will need to register a new account.

Step 2: try to replicate the error.

Step 3: fix the bug.

Step 4: submit the PR, and mention @shaunanoordin to get my attention.

If you need any help, please comment away on this Github Issue! (Note: it may take me a few days to reply sometimes, as I cycle through multiple projects.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants