Last modified: 2014-11-17 10:35:30 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 4995 - Ability to block users from uploading files or EmailUser only
Ability to block users from uploading files or EmailUser only
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: Lowest enhancement with 27 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6670 (view as bug list)
Depends on: 14636
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-15 07:43 UTC by brianna.laugher
Modified: 2014-11-17 10:35 UTC (History)
16 users (show)

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


Attachments

Description brianna.laugher 2006-02-15 07:43:27 UTC
It would be useful to be able to *only* block users from uploading files,
especially at Commons. This would be used for users who continue, after a
warning, to upload files without  complete source and licensing information.

A full block is too harsh for a new user that may not understand copyrights
(even if their images are legitimate) and may not speak the same language as the
admin. Allowing them to keep editing allows them to contact people who can help
explain copyright issues to them and  shouldn't cause the same outrage that
blocking tends to.

Is this really necessary? I found two users who could benefit from it, in one
day of casually reading the recentchanges.
Comment 1 brianna.laugher 2006-02-15 07:52:53 UTC
Maybe related to [http://bugzilla.wikipedia.org/show_bug.cgi?id=1535], a request
to block users from specific namespaces only.

Also, if it's helpful, I'm [[commons:User:pfctdayelise]]. 
Comment 2 David Benbennick 2006-02-15 11:15:54 UTC
(In reply to comment #1)
> Maybe related to [http://bugzilla.wikipedia.org/show_bug.cgi?id=1535], a request
> to block users from specific namespaces only.

Just to clarify, this request is not actually the same as bug 1535.  We
specifically want to allow people to edit image pages (so they can add the
source information for their uploads, for example) without being able to upload
new images.
Comment 3 Platonides 2006-05-10 16:20:26 UTC
When implementing this, think in adding an autoconfirmed-required-for-upload
feature.
Comment 4 xkernigh 2006-05-11 20:57:55 UTC
Related thread on commons-l: 
http://mail.wikipedia.org/pipermail/commons-l/2006-May/000226.html 
Comment 5 Brion Vibber 2006-05-11 22:11:28 UTC
The suggestion in that post wouldn't work; permissions from groups 
are additive so the default permission would always override it.
Comment 6 brianna.laugher 2006-05-31 09:09:33 UTC
Is it possible to implement this only on Commons, if nothing else? Can we not
create a user group that is exactly the same as users at the moment except they
can't upload?

Bureaucrats can change user groups, right? Even if only bureaucrats could do
this, it would still help. We have some active bureaucrats now. 
Comment 7 Rob Church 2006-05-31 13:14:58 UTC
Bureaucrats can't do free changes to user group memberships on Wikimedia sites;
via MakeSysop, they can add users to the sysop and bureaucrat groups, and via
MakeBot, they can add or remove users to/from the bot group.

We'd need a reliable backend method (fiddling with permissions wouldn't work,
per comment 5 et al) and a frontend we could *use*.
Comment 8 Judson (enwiki:cohesion) 2007-05-06 05:34:52 UTC
This would be useful on enwiki also, for the same reasons. I wouldn't want to
limit to bureaucrats though.
Comment 9 Andrew Garrett 2007-07-06 07:18:30 UTC
Possibly part of bug 674. I'm thinking of blocking users from Special:Upload, or something like that.
Comment 10 Andrew Garrett 2007-07-09 13:30:55 UTC
I intend to make an overhaul of blocking, integrating it with protection and allowing very general, and very granular blocks. Per-permission blocking is an intended part of these changes, and will solve this bug.
Comment 11 Skander 2007-07-16 16:45:28 UTC
There's one thing I don't understand:

Users ''can'' be blocked from emailing (i.e. the Special:Emailuser function is disabled for them)
Users ''cannot'' be blocked from uploading (i.e. the Special:Upload function would be disabled for them)

Why can't this be implemented?
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-16 16:52:56 UTC
It can be, just nobody's done it.  Werdna is apparently working, or thinking of working, on a much more robust blocking system that should allow any number of things to be blocked separately, so I'd say this will more likely than not be fixed within a few months, but no saying for sure.
Comment 13 Chad H. 2007-07-16 17:02:05 UTC
(In reply to comment #11)
> There's one thing I don't understand:
> 
> Users ''can'' be blocked from emailing (i.e. the Special:Emailuser function is
> disabled for them)
> Users ''cannot'' be blocked from uploading (i.e. the Special:Upload function
> would be disabled for them)
> 
> Why can't this be implemented?
> 

In addition, it's impossible to *just* block Special:Emailuser. That's an additive block, such that they're already blocked, and you block their access to e-mail in addition to it. Just as autoblock is additive. So to implement it in that fashion (which would be easy) is exactly against what you're suggesting.
Comment 14 Filip Maljkovic [Dungodung] 2008-01-05 19:28:31 UTC
*** Bug 6670 has been marked as a duplicate of this bug. ***
Comment 15 Mike.lifeguard 2008-12-28 21:56:12 UTC
(In reply to comment #7)
> Bureaucrats can't do free changes to user group memberships on Wikimedia sites;
> via MakeSysop, they can add users to the sysop and bureaucrat groups, and via
> MakeBot, they can add or remove users to/from the bot group.
> 
> We'd need a reliable backend method (fiddling with permissions wouldn't work,
> per comment 5 et al) and a frontend we could *use*.

We're using Special:UserRights for everything now, but I'm not sure that's the best way to go about this - it should be integrated into blocking, not into user rights.
Comment 16 Thomas Bleher 2009-10-22 06:42:13 UTC
Can't this be implemented using $wgRevokePermissions?
Just add

  $wgRevokePermissions['blockedfromupload']['upload'] = true;

or something like that (haven't tested the exact syntax) and add users to be blocked to the blockedfromupload group.
Comment 17 Thomas Bleher 2009-10-22 06:57:19 UTC
On second thought, this solves only one half of the problem, because there's no way to automatically remove someone from a group after (say) 30 days. So it's not possible to completely emulate expiring blocks that way. Or did I overlook something?
Comment 18 Platonides 2009-10-22 16:29:18 UTC
Not a seriois problem for commons, since we could have the users request their upload rights being restored (and thus review that they actually fixed their images).
Comment 19 Chad H. 2009-10-22 16:31:14 UTC
I don't really consider that a solution, moreso a workaround (TBH, I never liked the idea of $wgRevokeGroups anyway, but I digress...)

What we really need is to finally rewrite blocking to be permission-based.
Comment 20 Max Semenik 2010-03-23 11:26:59 UTC
WONTFIX per http://toolserver.org/~mwbot/logs/%23mediawiki/20100323.txt
Just a waste of everybody's time, developers and wiki users.
Comment 21 Bryan Tong Minh 2010-03-23 11:30:03 UTC
For enwiki perhaps, but not for Commons. Reopening.
Comment 22 Chad H. 2010-03-23 11:34:38 UTC
As I said in channel, this is technically feasible after bug 14636 is done. It just happens to be really low priority. 

Note to potential patch contributors: Do NOT implement this like e-mail blocking was. Tacking another single-purpose column onto the ipblocks table is a Bad Idea. See the blocker if you really want to do this right. Thus, this is resolved LATER until that time.
Comment 23 Rd232 2011-11-23 22:48:52 UTC
(In reply to comment #22)
> As I said in channel, this is technically feasible after bug 14636 is done. It
> just happens to be really low priority. 
> 
> Note to potential patch contributors: Do NOT implement this like e-mail
> blocking was. Tacking another single-purpose column onto the ipblocks table is
> a Bad Idea. See the blocker if you really want to do this right. Thus, this is
> resolved LATER until that time.

Just to point out that while this may be "really low priority" for most wikis, that is not true for Wikimedia Commons. COM:BUGS lists it as a priority, noting "This is desirable to force users to correctly annotate their existing images and read the [[Commons:licensing|licensing]] rules before uploading any additional images."
Comment 24 Brion Vibber 2011-11-29 21:42:12 UTC
Reopening; seems sensible in this day and age.
Comment 25 Khaled El Mansoury 2012-04-26 03:28:22 UTC
I am considering looking into this, but can someone tell me why the example given in Comment 16 is not a solution to this?
$wgRevokePermissions['blockedfromupload']['upload'] = true;
Comment 26 Khaled El Mansoury 2012-04-26 03:40:57 UTC
Or at least a semi-solution if we assume that bureacrats do this job manually.
Comment 27 Chad H. 2012-04-26 11:41:29 UTC
(In reply to comment #25)
> I am considering looking into this, but can someone tell me why the example
> given in Comment 16 is not a solution to this?
> $wgRevokePermissions['blockedfromupload']['upload'] = true;

Did you see my objections in comment 19?
Comment 28 Victor Vasiliev 2012-04-26 11:44:05 UTC
Russian Wikipedia implements this by automatically giving out a revokable uploader flag.

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


Navigation
Links