Hide_email_address_taken דורש שינוי טקסט לאיפוס סיסמה

סיכום מבוסס בינה מלאכותית

In a discussion about the ‘hide_email_address_taken’ setting in Discourse 2.8.0 beta10, Frully initially reported that while the setting correctly modifies password reset outcome text to protect email privacy, the instructions still misleadingly suggest usernames can be used — even though only emails trigger actual password reset emails. This could confuse users who enter usernames and expect emails. sam and rorycb couldn’t reproduce the issue on latest versions. Frully later suspected it was a caching issue, confirmed the behavior was correct on a fresh device, and apologized for the false report — concluding the issue was likely user error. The thread highlights the importance of clearing cache when testing site setting changes and confirms the feature works as intended in current builds.

2.8.0 beta10 - hide_email_address_taken needs (automatic) tweaks to the site settings, or a warning to edit them to make sense.

If using the new feature 2.8.0.beta10: API Improvements, Domain Restricted Invite Links, Tab to Indent, and more

image

Enabling the setting changes the outcome text from a password reset of “an account matching xyz/foo@bar.com was found, and an email was sent” to “if an account matching xyz/foo@bar.com exists it will get an email with reset instructions”. good. Problem: It doesn’t change the password reset instructions regarding ‘enter the username or password to initiate a reset’.

When doing a password reset from the login popup, the new site setting requires an email address and not a username, but the instructions seem to allow both, and outcome make it seem like it worked:

No email is sent if a username is entered instead of an email, but the outcome text indicates that it should have worked.

Instructions don’t change regardless of the site setting:

I foresee lots of head-desk when people are sure they have the right username and never get password reset emails.

2 לייקים

I am having trouble reproducing this on latest:

Can anyone else reproduce the issue?

2 לייקים

I suspect it may have been a cached page issue. I was testing in an incognito tab and refreshing between setting changes. The localization text seems right and in mobile I get the correct behaviour. Will try again when I’m near a computer. Apologies if this was a red herring.

Edit: trying again from a new computer with no cache…it is correct. moral of the story…be more thorough I guess. Thanks for looking into it friends!

3 לייקים

I can’t reproduce it on my test instance running latest either.

4 לייקים