Usability: Users shouldn't be able to block themselves

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

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

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.

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]

Moving all usability issues to Drupal - component usability.

Users can cancel their own accounts now in D7 and there is already an existing issue to prevent deletion of uid 1 (#46149: Prevent account cancellation for uid 1). There already exist contrib modules to help with this so I think it's good to set this as won't fix.