Last modified: 2008-01-05 19:28:31 UTC
Serbian wikipedia has recently voted a policy regarding uploading images. With it, there's a "punishment" for people that don't obey to our policy. This punishment is basically a restriction on uploads. Now, we can delete all the images that the punished user uploads, but it would be much better if there were a group/right which could be assigned to the user in question, so the user could do everything normaly except upload (and reupload, of course). The voting took place here [1] and the official policy is here [2]. The group would be called "noupload" or "безслика" in Serbian. Needless to say, only bureaucrats would have control over this (i.e. assigning the group). [1] http://sr.wikipedia.org/wiki/Википедија:Гласање/Политика_слања_слика [2] http://sr.wikipedia.org/wiki/Википедија:Правила_о_коришћењу_слика
There's no way to make such a group.
As Brion said over IRC, userrights are additive, so this is not doable with the current rights system.
That doesn't make it a WONTFIX.
I can think of a couple of methods for doing this, one a quick hack, and one a bit cleaner. The hack would be to add a second permission check in UploadForm::execute(), something like: if( $wgUser->isAllowed( 'noupload' ) ) aborting the process if that's true. We would then avoid assigning that permission in the defaults, and document the abnormal behaviour. However, this creates, well, abnormal behaviour which isn't consistent with the rest of our permissions mechanism. The second method would be to introduce another block flag to prevent image uploads. This is much cleaner, but requires a schema change and takes a bit longer to implement.
A block flag probably makes the most sense in general.... However if we keep adding little block flags like this, issues of expiration are raised -- a 'higher' block that's added temporarily would remove the preexisting upload block when it expires.
Duping to bug 4995, as that one predates this and they deal with the same thing. Would be good if someone had this on their TODO list :) *** This bug has been marked as a duplicate of bug 4995 ***
