Wikimedia Bugzilla is closed!

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