Users are able to block themselves from Drupal

I will work in this

Modified AccountForm to prevent status field rendering only if the account editor is the same user to prevent self-blocking

Pretty sure this is intentional and required: #8-75: Let users cancel their accounts →

Yeah this should be closed works as designed.

This is required in some places.

We have the "Cancel own user account" and "Select method for cancelling account" permissions which make sense for the use case of cancelling your own user. As a requirement, that makes sense because on some sites, you may want to allow users to remove their own user.

If a site is legally mandated to keep the information about author even after canceling the user, the site administrator, would have to disable the "Select method for cancelling account" permission from users, and configure the user cancellation to "Disable the account and keep its content".

I'm not sure I see what's the use case where you'd explicitly have to be able to block your own user outside of the canceling scenario.

Agree with @lauriii in #7. Thinking of something like facebook where I can cancel my account but I can't block.

Moving to NW for test coverage

Added test case to validate the existence of status field for 2 situations:

1. When user edits itself
2. When user edits other user

PHPSTAN: broken +80 chars comment into two lines in test.

oily → changed the visibility of the branch 11.x to hidden.

Removed a line from the test, just assert for first radio button. See example in UserSubAdminTest.php line 40.

Test-only test fails as it should. Pipeline all green.

Hello,
Tested and verified on Drupal 11.
MR applied successfully.
Its working as expected "Status" field is hidden from the user when rendered for the current user.
Attachments

Thank you for the review @sagarmohite0031. Based on that I am changing to RTBTC.

Please don't RTBC based on someone else's comment unless they explicitly state they have reviewed the code. For all we know @sagarmohite0031 only applied the patch without checking the code.

Left some feedback that warrants setting back to NW.

Usually form fields are hidden from access via #access instead of removing them to keep the form structure intact for alters.

Yeah I mentioned that option in the review. In this case I would even consider disabling it so admins don't face varying forms depending on which user they're editing and end up getting confused.

Something along the lines of: As an administrator, you cannot block your own account. Either [cancel it] or ask another administrator to block it for you.

@kristiaanvandeneynde Thank you for #19. I will check what the docs say on it. The value of the RTBTC was the evidence in screenshots which although not fullproof is a lot better than a simple statement. If what you say is true then if the review had merely stated, 'checked the code. All good.' then that would ensure the review was authentic? Hmm. I think what makes reviews reliable is having experienced contributors like yourself do the review. But there is no mechanism for that.

For what it's worth I always considered the R in RTBC as "Reviewed the code" whereas the T means "Tested the outcome / changes". Non-technical users can provide great feedback for the latter, but at least one technical person needs to check the former for an issue to truly be RTBC. It causes a lot of noise for committers if a bunch of issues are set to RTBC and none of them meet the code quality gates.

#23 Thank you, interesting to see it from your angle as a committer.

Reverted previous changes, added a condition to #access attribute to make it false if user self-editing according to @kristiaanvandeneynde's suggestions. Updated branch with lastest changes from main 11.x branch.

Appears to need a rebase. Have not re-reviewed

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

As I mentioned earlier, I think even better UX would be to disable the field and have a description explaining why it's disabled. But I'm not blocking the issue on that as you could argue an admin would be able to figure out that they're editing their own account and it would be unwise to block their own account. Will leave to committers to decide whether we need the better UX here.

There is still a line of documentation referring to people as objects, which we really should not do. If you resolve that and make sure there's no merge conflict, then I'm fine to sign off on this.

Hi folks,

I've updated the fork and rebased the branch. I re-applied my changes and incorporated @kristiaanvandeneynde's UX suggestions. Essentially, I had to rewrite all (although it wasn't that much).

Rebase seems good and feedback appears to be addressed.

Looks good to me too. Thanks a lot!

One minor nitpick that shouldn't hold up committing this is that the message assumes the editor is an admin. This will almost always be the case, but perhaps the message could be cut down to:

You cannot modify your own account status