When testing this functionality for the User Manual documentation, I am not able to reset my password and the issues referenced in Austin’s comment occur for me - former password no longer works (though as Don mentions shouldn’t matter anyway.) Another member of our sub-team was successfully able to reset his password. I tested various user account access options and this does not seem to make a difference.

I was able to successfully reset my password as a non-admin user.

Unfortunately, there isn’t much we can do to manage what happens when spam systems catch messages, as they often manipulate the URLs contained within in ways we cannot predict. This is certainly a good thing to be aware of, however. System administrators will likely be on the hook for addressing any issues like this that arise with their systems. We could maybe add some text to the password reset email informing users to beware of messages being manipulated by spam systems if it happens too frequently in the wild.

We discussed how once a user clicks the reset link, the original password cannot be used to log in to that account any longer. This is true, but shouldn’t be an issue in real-world use because the user has presumably already forgotten that password to begin with.

I was unable to reproduce a case where a confirmation message was not displayed after the password was successfully reset. If anybody can reproduce this, please report back with exact steps to do so.

With respect to password complexity, ideally we would someday apply the same standards to password creation and/or user changes as well, or at least make them available, but right now it has only been implemented for the reset. The actual requirements are that the password be from 8 to 30 characters long, as well as being “complex enough” according to some internal parameters set for the password testing component being used. These parameters are not straightforward, so although it would be nice to make them configurable at some point, it’s difficult to provide a simple explanation for how changing them will impact the actual requirements for the user. The clearest we can be is to tell users to avoid common names and phrases, or simple patterns.

If I missed anything, or if there are additional questions, please let me know.

@Donald Smith would you please put some notes on here to indicate your findings about the observations from testing? Once that’s done you can change the status back to Ready for Testing.

@Donald Smith Just putting a note here that it would be good to talk about this feedback in our sprint review.