While an account is pending approval, the error message shown when logging in and when requesting a new password are confusing

I changed the "request a new password" function to to be able to know if the account is enable or not.

Patch attached.

The message printed when you try to request a new account in a blocked account is right now : "Sorry, the account %name is not enabled."

The message should be heavily discussed on my mind.
We can't say "Your account is still pending" because we don't know if this account was disabled by an admin or if it is really still waiting for an approval.
On the other hand, we can't say that the account is disabled, because that would make users thinks they have done something wrong.
But ... the "is not enabled" maybe not the right way to say that. Maybe someone here got a better idea about that.

#1: 1087132.patch queued for re-testing.

This is not a bug. The reset password feature should not disclose the status of the account.

Damien, I agree that password reset shouldn't disclose the status of the account. However, I also agree with mlncn that "Drupal is lying to its users and sending them in an infinite loop". I think returning an inaccurate (wrong) message should be considered a bug. Clients have told me their websites are broken due to this issue.

I see 2 options:
1) Update the current 'wrong' message to be more generic. For example: Sorry, mary@example.com is not recognized as an activated user name or e-mail address.
2) Return the 'password reset instructions have been sent' message, and send an e-mail which says 'You requested a password reset, but your account is not currently active. This could be for reasons X,Y,Z. It can only be activated by a staff member. If/when your account is activated, you will receive your log in information.'

Option 1 may still confuse users, but is at least not 'lying'.

Applied patch #1 working fine sharing the screenshot...

Thanks for reporting and working on this. Currently the message in the user_pass_submit() differs from the text in the issue summary, as the message was changed. The actual message is:

If %identifier is a valid account, an email will be sent with instructions to reset your password.

This message does not disclose an account status. If the account is disabled, it is not possible to change the password. The issue summary is correct, the user can be misled by the displayed message.

I compared the D7 code with Drupal 10 and it seems like the situation is the same - https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/user/... . The password reset link is not sent for inactive accounts.

Related issues:
#1521996: Password reset form reveals whether an email or username is in use
#3353185: Password reset form error makes no sense when the account is locked
#3292874: Invisible and wrong error message when flood controlled users ask for a password reset mail

Re #7:

I see 2 options:
1) Update the current 'wrong' message to be more generic. For example: Sorry, mary@example.com is not recognized as an activated user name or e-mail address.
2) Return the 'password reset instructions have been sent' message, and send an e-mail which says 'You requested a password reset, but your account is not currently active. This could be for reasons X,Y,Z. It can only be activated by a staff member. If/when your account is activated, you will receive your log in information.'

1 - The proposed message is still not entirely correct. User can also be under flood control and in that case the account is not blocked at all. So the message would needs to be tweaked a bit.

2 - This was also proposed in #3353185: Password reset form error makes no sense when the account is locked. I think this is an interesting idea, but it would be a Feature request.

---------------

So to summarize this. If we are going to do any changes here, we should start with backporting what was not backported from #1521996: Password reset form reveals whether an email or username is in use in #3200198: [D7] password reset form prevent revealing email or username in use, as we still reveal the account status if the user account is under flood control. Not sure we skipped the removal intentionally. See: https://git.drupalcode.org/project/drupal/-/commit/5f0435769a07348b89bbb...

-        if (!$this->flood->isAllowed('user.password_request_user', $flood_config->get('user_limit'), $flood_config->get('user_window'), $identifier)) {
-          $form_state->setErrorByName('name', $this->t('Too many password recovery requests for this account. It is temporarily blocked. Try again later or contact the site administrator.'));
-          return;
-        }

Then we need to decide on D10 issues and once the decision is made, we can backport the same solution to D7. So if there is any interest in fixing this in D7, it would be great to focus and help with the D10 issue. Then we can continue here. Moving this as postponed, until there is a decision in D10 / progress possible.

Thanks again!

I edited the title to make clearer what the issue purpose is.

This issue was originally created before the message was changed (the new wording was mentioned in #12), and the new wording addresses the "option 1" recommendation from comment #7.

Personally, I think this issue should be closed as duplicate (or as outdated). The related issues sufficiently address what this issue was created for.