Last modified: 2010-02-10 16:05:09 UTC
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 too will be noticed by the community hence not an issue, and is easier to allow block/unblock on that basis than to figure what unblocks they may need to do to remedy a problem.
There's two solutions to this. 1) The easy way is to just add isBlocked() checks to all of these various features, but that's kind of icky in the long run 2) Fix bug 14636, which calls for per-permission blocking. So you could click a "block from everything" button or unlock specific permissions, such as blocking deletions or uploading.
There are too many permissions for this (now and future) - this would require admins blocking a user to consider a forest of checkboxes when really it's one item and automatic (shouldn't need any checkbox). Maybe a workaround (ugly) is to change admins from usergroup "sysop" to usergroup "blocked-sysop" and back? Or to replace however "is_sysop" is calculated, by a different test, "is_unblocked_sysop()"? Not a coder, hence no idea how is best.
*** This bug has been marked as a duplicate of bug 15641 ***
