Last modified: 2011-10-07 14:05:42 UTC
When blocked, on one's own talk page one: *can load the move form, but cannot submit (although the blocked header which is returned is malformed) *can change the protection levels *can delete the page, but cannot undelete (but can recreate as intended) Additionally, when blocked, one can block and unblock other users. Expected results: *One should not be able to undertake any admin functions on one's own talk page whilst blocked *One should not be able to block or unblock other users whilst blocked
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.
(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.
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. ***
(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.
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).
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.
Fixed in r85005.
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.
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.
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).
