Last modified: 2014-11-17 10:35:30 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.
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]].
(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.
When implementing this, think in adding an autoconfirmed-required-for-upload feature.
Related thread on commons-l: http://mail.wikipedia.org/pipermail/commons-l/2006-May/000226.html
The suggestion in that post wouldn't work; permissions from groups are additive so the default permission would always override it.
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.
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*.
This would be useful on enwiki also, for the same reasons. I wouldn't want to limit to bureaucrats though.
Possibly part of bug 674. I'm thinking of blocking users from Special:Upload, or something like that.
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.
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?
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.
(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.
*** Bug 6670 has been marked as a duplicate of this bug. ***
(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.
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.
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?
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).
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.
WONTFIX per http://toolserver.org/~mwbot/logs/%23mediawiki/20100323.txt Just a waste of everybody's time, developers and wiki users.
For enwiki perhaps, but not for Commons. Reopening.
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.
(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."
Reopening; seems sensible in this day and age.
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;
Or at least a semi-solution if we assume that bureacrats do this job manually.
(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?
Russian Wikipedia implements this by automatically giving out a revokable uploader flag.
