Last modified: 2006-06-05 14:50:45 UTC
Blocking a user does not prevent them from doing anything except actually editing a page, which means that blocked users can still rollback, (un)protect, block/unblock, etc. if they have those abilities normally available to them. I suggest this is modified so that a blocked user is prevented from doing anything which alters the database, apart from unblocking themselves.
(In reply to comment #0) > I suggest this is modified so that a blocked user is prevented from doing > anything which alters the database, apart from unblocking themselves. "anything which alters the database" are also "actions" which do not affect other users: 1. changing preferences, including e-mail address, password etc. 2. adding / removing items to the own whatch list I thing that it would be fair to allow blocked users these actions. Regards Reinhardt [[user:gangleri]]
This glitch is not of the highest priority, nor is it "critical". Incidentally; if endorsing the ability to self-unblock, then why bother restricting the other stuff; the user can just unblock themself, then carry on.
Because if we do enable rollback seperately from adminship (which there is some demand for), users with rollback but not admin shouldn't be able to rollback.
Well, technically speaking, rollback assignment is a configuration issue. Users with rollback don't have access to the blocks, however, and so couldn't unblock themselves. Rollback needs merely to be tweaked to check that the user isn't blocked first.
That's exactly my point.
(In reply to comment #1) > "anything which alters the database" are also "actions" which do not affect > other users [..] Yes, you make a sensible point. I didn't think of that when writing. I agree that blocked users should be allowed to perform these tasks too. My wording was unclear. (In reply to comment #4) > Well, technically speaking, rollback assignment is a configuration issue. Users > with rollback don't have access to the blocks, however, and so couldn't unblock > themselves. Rollback needs merely to be tweaked to check that the user isn't > blocked first. Yes, that is what this bug report is for. :) Chris
In includes/User.php, in function isAllowed add the folowing... //If the user wants to delete or undelete a page and he is blocked don't allow him to do so. if( ($action == 'delete' || $action == 'undelete') && $this->isBlocked() ){ return false; } //If the user wants to protect or unprotect a page and it's blocked don't allow him to do so. if( ($action == 'protect' || $action == 'unprotect') && $this->isBlocked() ){ return false; } ...i guess it should work.
Fixed in CVS HEAD. Blocked users can now not use rollback, or delete pages. Protection levels are read-only when the user is blocked, and the undelete page works like it does for users without that permission.
Does that imply that blocked users can still block other users?
(In reply to comment #9) > Does that imply that blocked users can still block other users? Yes.
Wouldn't it be more appropriate to still allow a blocked admin to UNblock, but not allow him to Block? Should be an equally simple code tweak.
The problem with that is an admin woulnd't be able to undo unblocks made in error.
I believe that the ability for admins to block/unblock others while blocked should be limited. Admins should only be able to unblock themselves while blocked, in case of an autoblocker. Chris
1) What's "themselves"? An IP block that hits an admin isn't explicitly linked to their account. In cases like AOL proxies it may not even be consistent from hit to hit. 2) If they can unblock themselves, they can then block and unblock anyone else. So what does some kind of limitation here actually accomplish?
Thanks for explaining that Brion, I didn't think of that. In that case, just limiting the ability of blocked users to block others would serve. Chris
Since everything that was going to be done is done already, shouldn't this be marked as RESOLVED?
