@MaxSem Great point. The current language may be too vague. Prateek and I came up with the wording right before estimation, and I agree that it can be improved.

@Prtksxna Any thoughts? Maybe we can add an extra sentence, so the full paragraph states: "However, if you did not generate this request and want to prevent unsolicited emails, you may want to enable the password reset preference. This enhances the privacy of your password reset, by requiring both the username and email address in order to generate a password reset email."

@MaxSem, yeah, password reset preference doesn't really explain much, and we don't call it that on the settings page either.

I like your suggestion @ifried, but we could possibly eliminate the phrase — password reset preference completely: However, if you did not generate this request and want to prevent unsolicited emails, you may want to enable the preference that requires both username and email address to generate password reset emails from Email Options. This may reduce the number of such incidents.

@Prtksxna Thanks for the suggestion! I also see why we may want to remove the mention of "password reset preference," since it's confusing and people don't know what it means. I just reworded the sentence so it was less wordy and more straight-forward. We can finalize it in our meeting today. Here's what I had in mind:

However, if you did not generate this request and want to prevent unsolicited emails, you may want to update your Email Options. You can require both username and email address to generate password reset emails. This may reduce the number of such incidents.

@MaxSem Thanks for your patience! :) We have updated the ticket with the new wording and it's ready for development.

Looks good 👍🏽

Change 540220 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/core@master] Mention requiring email address in password reset emails

https://gerrit.wikimedia.org/r/540220

Ready for review.

Is 540220 the patch that's ready for review? It's commit message says WIP. Or do you mean the underlying two patches for that one?

Err, I both forgot to update the commit message and it's kinda moot, considering that it depends on two changes that have been waiting to be merged for a month.

I can +2 the base patch.

Change 540220 merged by jenkins-bot:
[mediawiki/core@master] Mention requiring email address in password reset emails

https://gerrit.wikimedia.org/r/540220

The password reset email now looks like (on Gmail's web client):

@MaxSem Can we limit the width of the new paragraph, so it is consistent with the rest of the email?

Change 552966 had a related patch set uploaded (by Ammarpad; owner: Ammarpad):
[mediawiki/core@master] Add linefeed in password reset message

https://gerrit.wikimedia.org/r/552966

Change 552966 merged by jenkins-bot:
[mediawiki/core@master] Add linefeed in password reset message

https://gerrit.wikimedia.org/r/552966

@dom_walden, updated to this

In T233969#5696170, @Ammarpad wrote:

@dom_walden, updated to this

Thanks!

I think the acceptance criteria have been met. Bear in mind that, because the emails are plain text (I do not think we support HTML), the "Email Options" text is not a link.

I have not looked at the width of the paragraph in other languages. Presumably the translations would potentially need to add linefeeds as well.

Moving to Product Sign-Off.

I'm unable to see the behavior change when I tested on https://test.wikipedia.org/. Can someone look into this? Thanks! Tagging @Mooeypoo

In T233969#5806411, @ifried wrote:

I'm unable to see the behavior change when I tested on https://test.wikipedia.org/. Can someone look into this? Thanks! Tagging @Mooeypoo

It works for me. The text only shows up when the feature flag is turned on and the PRU setting is not checked in your user profile. If the feature flag is on and the PRU preference is not checked then the last paragraph (""However, if you did not generate this request and want...") will be appended to the email's body.

@ifried is the PRU setting unchecked in your user profile?

I have tested this, and the message appears (see screenshot from email sent from testwiki) when the user has not yet turned on PRU in Preferences. This behavior is fine, so I'll mark this work as Done.