gangleri wrote:

(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]]

robchur wrote:

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.

nick_tarleton wrote:

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.

robchur wrote:

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.

nick_tarleton wrote:

That's exactly my point.

chris wrote:

(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

mickflemm wrote:

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.

robchur wrote:

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.

p_simoons wrote:

Does that imply that blocked users can still block other users?

robchur wrote:

(In reply to comment #9)

Does that imply that blocked users can still block other users?

Yes.

p_simoons wrote:

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.

pmjcovello wrote:

The problem with that is an admin woulnd't be able to undo unblocks made in error.

chris wrote:

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?

chris wrote:

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

titoxd.wikimedia wrote:

Since everything that was going to be done is done already, shouldn't this be
marked as RESOLVED?