Usability: Users shouldn't be able to block themselves

More of a feature request than a bug, plus patch no longer applies...

Er? Patch still applies, just with an offset. But here's a re-roll anyway which will apply cleanly...

Also changing status back to bug... if nothing else, this is a UI problem. Accidentally clicking that radio button (which is possible, since clicking anywhere on the "Blocked" label will cause it to switch) while changing something else on the form will render your admin user completely useless after you log out, remediable only by editing the database if you have no other users with administer user privileges. This can't possibly be intentional behaviour that would require a feature request to change.

I tested the patch. It's simple and it makes sense.

You're absolutely right. I also edited the patch to remove the ability to delete user 1.

Committed to 5 and 4.7.x.

patch was reverted as the current way s intentional according to Dries.

If it is intentional, what is the intention?

Perhaps there is a tiny use case for blocking user 1, but that does not mean that this is not a serious bug which needs to be addressed.

It is only in the case when there is at least one other user with "administer users" permissions that this action is reversible. In all other cases, it permanently screws up your Drupal site. It is also one of many useless options which are displayed when you create user account 1, so it is confusing as well. If Drupal can be hosed from the UI, it is broken.

The only thing I would see as acceptable is to add a check to see if there is another user with the permissions to unblock user 1. Otherwise, we should not show the blocking option (i.e. when creating the first account and in most other cases). However, this still does not prevent you from later deleting the user who can restore user 1 and still lock yourself out.

Deleting user 1 is certainly not desirable, as it is impossible to reverse.

Locking your Drupal site and throwing away the keys never sounds like a good idea. If you do need to maintain control, why not simply keep the password to UID 1 secret?

As an alternative for the blocking, we could make it so you can never block yourself, only others. That way you can only block user 1 if you are another user who is also priviledged.

Deleting user 1 should IMO still be completely disallowed.

Here's a patch that does #8 above. Removes the delete button and the status radios when editing your own account

Okay, after some discussion on #drupal, we've agreed on the following:

• Blocking user id 1, while useful in rare cases, should be avoided. Not being able to block yourself is a perfectly good solution to removing this confusion unless you really need it.
• Deleting user id 1 should not be allowed. You cannot recreate this account except for hacking the db, so it is a bug.

Seems reasonable.
But, since the issue seems controversial (and not new, too), could you be more specific on who is "we" (in "we've agreed on the following") ?

Here is a patch which (as per comment #10):
-Removes the ability to block yourself from /user/uid/edit
-Removes the ability to delete user 1 from /user/1/edit and denies access to /user/1/delete

To do:
-Remove the ability to block yourself from /admin/user/user
-Remove the ability to delete user 1 from /admin/user/user

Bumping this up again. Will try to take a look at those remaining issues today/tomorrow. Would be nice to get this in for this release.

Took a stab at the todos in #12. Error message now displayed if user 1 is being blocked or deleted.

+1
The patch does all what is mentioned in #12.
I even tried to fiddle the hidden fields in the deletion confirmation page, without success.
A nice error message appears every time: "You cannot delete the first user account".

Bad code, needs to use t(). There has been some resistance to this before. But personally, I think we should not allow users to lock themselves out. I'll defer to someone else though.

As noted by Steven, message needs to be translatable.

Enclosed messages with t() and removed the ability to block yourself from admin/user/user instead; Misread the todo in #12.

Stray x in the patch.

Looks good to me! I tried to delete/block user 1 from user/1, from user/1/delete, and from admin/user/user, and in each case I was averted. :)

I was able to delete/block non-user 1 users fine.

Marking RTBC.

Unavailable options should only be removed for permissioning purposes. Otherwise, disabling the element is preferred. THis should be true for the user status radios.

There is no need to load $account just to get the uid which you already have.

Setting an error on a group operation makes a dead end and wasted time selecting a group. Instead, I think the offending account should be removed from the select and a message set stating what happened.

There is something like three different things going on in this patch. What about splitting this up and concentrating on one at a time?

Unavailable options should only be removed for permissioning purposes. Otherwise, disabling the element is preferred. THis should be true for the user status radios.

There is no need to load $account just to get the uid which you already have.

Setting an error on a group operation makes a dead end and wasted time selecting a group. Instead, I think the offending account should be removed from the select and a message set stating what happened.

There is something like three different things going on in this patch. What about splitting this up and concentrating on one at a time?

Here's our situation...

We need to be able to block access to user/1 for other admin users. It's easy enough right now to edit user/1 and change the user name, e-mail, and password. This allows you to be able to block out access to user/1 to the person who should have access.

We're with the main parent organization. There are several "child" organizations under us. We want them to be able to do work on their site we've set up for them, but not be able to change the user/1 log-in so that it always belongs to us.

Is there a way to do this?

Based on the number of forum posts by newbies who have done this, I'm tempted ot set to critical...

Here a different, but creative, way to block admin account access as well: http://drupal.org/node/129299

http://drupal.org/project/paranoia

yes, but the point is the core UI.

I'd be happy even with that module, if it were updated for 5.x.

This issue recently came up in a review of Drupal posted by Dries to the development mailing list.

Related issue to disallow deletion of User 1: http://drupal.org/node/46149

And notes in the wiki suggested:

* ... add #access => $user->uid != $account->uid here. [chx]
* and an && $user->uid > 1 for kicks [dmitrig01]