Last modified: 2006-06-05 14:50:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3801 - Blocked users can do everything they normally can, except edit.
Blocked users can do everything they normally can, except edit.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-26 16:58 UTC by Chris Jenkinson
Modified: 2006-06-05 14:50 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Chris Jenkinson 2005-10-26 16:58:53 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.
Comment 1 lɛʁi לערי ריינהארט 2005-10-26 18:38:00 UTC
(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]]
Comment 2 Rob Church 2005-11-04 17:19:07 UTC
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.
Comment 3 Nick Tarleton 2005-11-04 18:04:54 UTC
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.
Comment 4 Rob Church 2005-11-05 17:07:51 UTC
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.
Comment 5 Nick Tarleton 2005-11-05 17:57:35 UTC
That's exactly my point.
Comment 6 Chris Jenkinson 2005-12-13 21:45:28 UTC
(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
Comment 7 Nick Kossifidis 2006-01-02 22:55:07 UTC
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.
Comment 8 Rob Church 2006-01-06 23:28:56 UTC
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.
Comment 9 p_simoons 2006-01-20 12:37:14 UTC
Does that imply that blocked users can still block other users?
Comment 10 Rob Church 2006-01-21 15:48:52 UTC
(In reply to comment #9)
> Does that imply that blocked users can still block other users?

Yes.
Comment 11 p_simoons 2006-01-23 01:16:58 UTC
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.
Comment 12 pmjcovello 2006-02-02 19:46:23 UTC
The problem with that is an admin woulnd't be able to undo unblocks made in error.
Comment 13 Chris Jenkinson 2006-02-08 18:54:00 UTC
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
Comment 14 Brion Vibber 2006-02-08 22:44:16 UTC
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?
Comment 15 Chris Jenkinson 2006-02-08 23:02:42 UTC
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
Comment 16 Titoxd 2006-06-05 07:47:12 UTC
Since everything that was going to be done is done already, shouldn't this be
marked as RESOLVED?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links