It can cause problems if user 1 is blocked from the site, and probably 99% of the time this is done this is an accident. This patch removes the UI for blocking user id 1. If it's desired to do this for security reasons, there's always the raw database manipulation option, which should suit advanced users without allowing newbies to totally mess up their sites.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webernet’s picture

Category: bug » feature
Status: Needs review » Needs work

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

webchick’s picture

Category: feature » bug
Status: Needs work » Needs review
FileSize
737 bytes

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.

beginner’s picture

Status: Needs review » Reviewed & tested by the community

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

Steven’s picture

Status: Reviewed & tested by the community » Fixed

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

Committed to 5 and 4.7.x.

killes@www.drop.org’s picture

Status: Fixed » Closed (won't fix)

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

beginner’s picture

If it is intentional, what is the intention?

Steven’s picture

Status: Closed (won't fix) » Active

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?

Steven’s picture

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.

AjK’s picture

Status: Active » Needs review
FileSize
1.65 KB

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

Steven’s picture

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.
yched’s picture

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") ?

webernet’s picture

Status: Needs review » Needs work
FileSize
2.06 KB

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

webernet’s picture

Version: x.y.z » 5.0-beta1
webchick’s picture

Version: 5.0-beta1 » 5.x-dev

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.

edmund.kwok’s picture

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

edmund.kwok’s picture

Status: Needs work » Needs review
serval-1’s picture

+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".

Steven’s picture

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.

webernet’s picture

Status: Needs review » Needs work

As noted by Steven, message needs to be translatable.

edmund.kwok’s picture

Status: Needs work » Needs review
FileSize
3.34 KB

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

edmund.kwok’s picture

Stray x in the patch.

webchick’s picture

Assigned: webchick » Unassigned
Status: Needs review » Reviewed & tested by the community

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.

drumm’s picture

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?

drumm’s picture

Status: Reviewed & tested by the community » Needs work

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?

jsimonis’s picture

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?

pwolanin’s picture

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

pwolanin’s picture

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

killes@www.drop.org’s picture

pwolanin’s picture

yes, but the point is the core UI.

jsimonis’s picture

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

webernet’s picture

Title: Don't provide interface to block user 1 » Usability: Users shouldn't be able to block themselves
Version: 5.x-dev » 6.x-dev

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

Gábor Hojtsy’s picture

And notes in the wiki suggested:

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

Sutharsan’s picture

Version: 6.x-dev » 7.x-dev
Component: user system » usability

Moving all usability issues to Drupal - component usability.

Dave Reid’s picture

Version: 7.x-dev » 6.x-dev
Component: usability » user.module
Status: Needs work » Closed (won't fix)

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.