Consider hiding the status message when admins cannot set a password on account creation

Hi,
I was able to reproduce the above mentioned bug.
I agree that hiding the message will eliminate the chances of confusion, when 'Admins cannot set a password when creating or editing an account.' is selected, as there is no option add a password when this option is selected.

Hi,
Made the changes to hide the message, when "Admins cannot set a password when creating or editing an account." is selected.
Please review.

Thanks & regards.

Thanks @diwakar07! Looks like there are tests that need to be updated. I am also not sure if the module maintainers will accept this change.

The OP concept makes sense.

If there's a situation where the message is appearing out of context then it should not show. I didn't think it showed in such situations anyway but the addition of the admin restrictions looks to have added it.

https://git.drupalcode.org/project/genpass/-/blob/2.1.x/genpass.module#L...
Not sure the MR covers all of the situations, although it does only appear to show for admin create user? Keeping with the similar style as the above it would be good where parts of conditions are stored in variables to be compared in the if statement to keep the line length to <80 and keep the code readable. And yes, tests need to be added to specifically test for the changed situation.

This boiled down to "if the admin is given the password field, let them know they didn't enter anything"; perhaps they had wanted to enter a password but they forgot. The password display setting also needed to be respected.

Updated the MR changed the logic, and added tests; Combining the condition meant that the password display setting was ignored, and caused more conditional checks that is needed for the admin - if the admin_mode was set to PASSWORD_ADMIN_HIDE then the messaging fell back to user settings instead which is not desired.

Awesome, thanks! Just updated the title to reflect that this change is good to make. I will manually test when I get a chance.

This change is straightforward and logical, with a passing test, so looks good to me. Thanks for actioning it so quickly!

Edit: I also did manually test it!

Ported to previous branch too.

This will actually trigger a release as there are number of commits in both branches that have been sitting around waiting for a reason.

Failure of "phpunit (next minor)" does not appear to be temporary so, 🐛 phpunit (next minor) failing Active

Automatically closed - issue fixed for 2 weeks with no activity.