Ability to block users from uploading files or EmailUser only
OpenPublic

Assigned To
None
Priority
Lowest
Author
bzimport
Blocked By
T16636: Blocking/Permissions Rewrite
Subscribers
gpaumier, Nemo_bis, He7d3r and 6 others
Projects
Tokens
"Like" token, awarded by Nemo_bis.
Reference
bz4995
Description

Author: brianna.laugher

Description:
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.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=7997
https://bugzilla.wikimedia.org/show_bug.cgi?id=21808
https://bugzilla.wikimedia.org/show_bug.cgi?id=43228

bzimport added a project: MediaWiki-Uploading.Via ConduitNov 21 2014, 9:05 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz4995.
bzimport created this task.Via LegacyFeb 15 2006, 7:43 AM
bzimport added a comment.Via ConduitFeb 15 2006, 7:52 AM

brianna.laugher wrote:

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

bzimport added a comment.Via ConduitFeb 15 2006, 11:15 AM

dbenbenn wrote:

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

Platonides added a comment.Via ConduitMay 10 2006, 4:20 PM

When implementing this, think in adding an autoconfirmed-required-for-upload
feature.

bzimport added a comment.Via ConduitMay 11 2006, 8:57 PM

xkernigh wrote:

Related thread on commons-l:
http://mail.wikipedia.org/pipermail/commons-l/2006-May/000226.html

brion added a comment.Via ConduitMay 11 2006, 10:11 PM

The suggestion in that post wouldn't work; permissions from groups
are additive so the default permission would always override it.

bzimport added a comment.Via ConduitMay 31 2006, 9:09 AM

brianna.laugher wrote:

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.

bzimport added a comment.Via ConduitMay 31 2006, 1:14 PM

robchur wrote:

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*.

bzimport added a comment.Via ConduitMay 6 2007, 5:34 AM

cohesion wrote:

This would be useful on enwiki also, for the same reasons. I wouldn't want to
limit to bureaucrats though.

werdna added a comment.Via ConduitJul 6 2007, 7:18 AM

Possibly part of bug 674. I'm thinking of blocking users from Special:Upload, or something like that.

werdna added a comment.Via ConduitJul 9 2007, 1:30 PM

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.

bzimport added a comment.Via ConduitJul 16 2007, 4:45 PM

shinywater wrote:

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?

bzimport added a comment.Via ConduitJul 16 2007, 4:52 PM

ayg wrote:

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.

demon added a comment.Via ConduitJul 16 2007, 5:02 PM

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

bzimport added a comment.Via ConduitJan 5 2008, 7:28 PM

dungodung wrote:

*** Bug 6670 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitDec 28 2008, 9:56 PM

mike.lifeguard+bugs wrote:

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

Tbleher added a comment.Via ConduitOct 22 2009, 6:42 AM

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.

Tbleher added a comment.Via ConduitOct 22 2009, 6:57 AM

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?

Platonides added a comment.Via ConduitOct 22 2009, 4:29 PM

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).

demon added a comment.Via ConduitOct 22 2009, 4:31 PM

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.

MaxSem added a comment.Via ConduitMar 23 2010, 11:26 AM

WONTFIX per http://toolserver.org/~mwbot/logs/%23mediawiki/20100323.txt
Just a waste of everybody's time, developers and wiki users.

bzimport added a comment.Via ConduitMar 23 2010, 11:30 AM

Bryan.TongMinh wrote:

For enwiki perhaps, but not for Commons. Reopening.

demon added a comment.Via ConduitMar 23 2010, 11:34 AM

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.

bzimport added a comment.Via ConduitNov 23 2011, 10:48 PM

rd232 wrote:

(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."

brion added a comment.Via ConduitNov 29 2011, 9:42 PM

Reopening; seems sensible in this day and age.

bzimport added a comment.Via ConduitApr 26 2012, 3:28 AM

prog4life wrote:

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;

bzimport added a comment.Via ConduitApr 26 2012, 3:40 AM

prog4life wrote:

Or at least a semi-solution if we assume that bureacrats do this job manually.

demon added a comment.Via ConduitApr 26 2012, 11:41 AM

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

vvv added a comment.Via ConduitApr 26 2012, 11:44 AM

Russian Wikipedia implements this by automatically giving out a revokable uploader flag.

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:41 PM
werdna removed a subscriber: werdna.Via WebDec 10 2014, 6:17 PM
Nemo_bis awarded a token.Via WebDec 12 2014, 8:00 AM

Add Comment