river wrote:

I believe blocking and unblocking users while blocked was discussed before and the decision was this should be allowed. (Unfortunately, I don't remember the reasons, or where that was.)

(In reply to comment #1)

I believe blocking and unblocking users while blocked was discussed before and
the decision was this should be allowed. (Unfortunately, I don't remember the
reasons, or where that was.)

Two scenarios I can think of:

A) There's only 1 sysop. He blocks himself. Now he can't unblock himself unless someone tweaks the database.

B) There's two sysops. One goes rogue and blocks the 2nd. 2nd is now incapable of doing anything.

I can't remember where this was discussed, but I believe these were the reasons.

majorly.wiki wrote:

(In reply to comment #2)

(In reply to comment #1)

I believe blocking and unblocking users while blocked was discussed before and
the decision was this should be allowed. (Unfortunately, I don't remember the
reasons, or where that was.)

Two scenarios I can think of:

A) There's only 1 sysop. He blocks himself. Now he can't unblock himself unless
someone tweaks the database.

B) There's two sysops. One goes rogue and blocks the 2nd. 2nd is now incapable
of doing anything.

I can't remember where this was discussed, but I believe these were the
reasons.

That's for blocking/unblocking themselves. We need the reasons for *other* users.

haistaes wrote:

The standard concept seems to be that you can't undertake any editorial or administrative action when blocked besides:
*editing your own talk page (to communicate)
*unblocking yourself (for technical reasons outlined above)

The matters I have highlighted, as comment #3 said, seem inconsistent with this. You should have to be unblocked (or unblock yourself) to do any more, adding a layer of accountability.

• Bug 21882 has been marked as a duplicate of this bug. ***

FT2.wiki wrote:

(Copied from bug 21882)

An administrator who is blocked, should lose the use of most admin tools,
except perhaps the passive IP Block Exemption, and the ability to block and
unblock.

Rationale:

Blocking admins happens very rarely, in general only when there is a concern
about present and immediate conduct, sysop account compromise and the like and
while waiting for the local temporary desysop process to be completed.

When an administrator account is blocked, it seems illogical that they cannot
edit, but they can delete, undelete, protect, unproptect, view deleted
material, and so on.

Admin tools are more sensitive and require more trust than editing tools. A
sysop account that is blocked, should lose the tool access until the matter is
resolved, subject to keeping IP Block Exemption (needed to post appeals or
responses) and block/unblock ability (for test purposes when an admin
self-blocks or their IP is accidentally blocked)

Misuse of the block/unblock tool will be noticed by the community and met by the further step of removing that account's sysop access if needed, hence not an
issue. It is easier to allow block/unblock on that basis than to figure what
unblocks they may need to do on various MW installations, to remedy a problem.

FT2.wiki wrote:

Noting also from bug 21882 that "per permission" blocking is not what's needed. There are very many permissions a user can have. This issue is one item and should ideally be automatic (shouldn't need any checkbox).

happy.melon.wiki wrote:

Access to block/unblock fixed in r64228: blocked admins cannot block or unblock other users, nor unblock themselves unless they have the 'unblockself' right.

It seems that blocked users with the appropriate rights can still import pages via XML.

happy.melon.wiki wrote:

Fixed in r85005.

rd232 wrote:

As far as I can tell blocked administrators still have access to some administrative rights, in particular "browserarchive", "deletedhistory", and "deletedtext". These should also be suspended when blocked. Indeed, with the sole exception of self-unblocking (because of mistakes and "rogue admin" scenarios in small wikis), I would have thought that blocked users should only have access to whatever user rights are associated with the "all editors" group.

At any rate, on Wikimedia wikis, having blocked administrators - potentially compromised accounts whose status is not yet clear enough to desysop - able to access deleted material, even for a few hours or days, seems BAD, given the WMF emphasis on these rights being sensitive.

happy.melon.wiki wrote:

This should be fixed in r93206. Feel free to reopen if you find any more permissions that admins shouldn't have while blocked.

Reverted in r93246.

Grr, r99211.

happy.melon.wiki wrote:

For reference, I like the implementation idea for this I brainstormed in r93246 CR (basically making "isblocked" an implicit group which we can then use with $wgRevokePermissions).