Wikimedia Bugzilla is closed!

Oh and forgot to say that there is mandatory confirmation page before each action. That's helluvalot of actions needed to clean up this mess.

Fortunately the actions to achieve this level of vadalism are just as unreachable and unusable as the actiosn to undo them :P (otherwise commons would've been a mess)

That's not true. The default settings for upload rights are:

$wgGroupPermissions['user']['upload']           = true;
$wgGroupPermissions['user']['reupload']         = true;
$wgGroupPermissions['user']['reupload-shared']  = true;

It's very much against the wiki that something cannot be reverted easily.

(In reply to comment #2)
> Fortunately the actions to achieve this level of vadalism are just as
> unreachable and unusable as the actiosn to undo them :P (otherwise commons
> would've been a mess)

This is not a fortune. The whole point of combating vandalism is that it usually takes 1/100 of the time to revert it than to do it.

(In reply to comment #3)
> (In reply to comment #2)
> > Fortunately the actions to achieve this level of vandalism are just as
> > unreachable and unusable as the actions to undo them :P (otherwise commons
> > would've been a mess)
> That's not true. The default settings for upload rights are:

I wasn't referring to the reachability in terms of user rights. I was referring to the fact that the interface for pretty much anything media-related  (except for caching) is terrible and under maintained in MediaWiki, both front- and backend.


(In reply to comment #4)
> (In reply to comment #2)
> > Fortunately the actions to achieve this level of vandalism are just as
> > unreachable and unusable as the actions to undo them :P (otherwise commons
> > would've been a mess)
> 
> This is not a fortune. The whole point of combating vandalism is that it
> usually takes 1/100 of the time to revert it than to do it.

Sarcasm. I was referring to the fact that it's somewhat fortunate that it's almost as complicated to vandalize in this area then it is to undo it. Obviously undoing should be just as easy.

(random comment to allow statuschange from unconfirmed to new)

Mark: I  disagree with the low importance. I would consider this if not blocker for 1.19, very important bugfix for 1.20.

I do wonder how Commons and other wikies handle this.

(In reply to comment #7)
> I do wonder how Commons and other wikies handle this.

I've asked on #wikimedia-commons and will check back if no one has updated this bug tomorrow.

vandalism without copyright or other problems usually is just reverted. 
If there are problems the version's file content may be hidden or the whole version be deleted. You also just delete the whole file page and restore all versions except the new vandal version - then you have hidden the whole incident.

I agree it would be best if we can just revert harmful uploads, or re-uploades, but usually users are blocked very fast, and we have very few uploads to delete or delete and hide. one more point, you must sign up to upload, most vandals don't make that effort.

(In reply to comment #10)
> usually users are blocked very fast
> we have very few uploads to delete or delete and hide.

Only applies to WMF projects (and not even to all of them).

Might I suggest simply raising the requirements for being able to upload? Say an adjustment to the 'autoconfirmed' user right.

Obviously, the slow reversion is not an ideal situation, but it would be better to prevent such a situation from arising in the first place...

Importance: Critical -> Enhancement. Ok, what's broken here? While I agree that MediaWiki should make combating vandalism easier, it currently allows to do that as described in comment #0. So asking for it being easier is just an enhancement.

About the bug itself:

Okay, this bug explains the problems, but what's the expected solution?

For the current bug title: "image upload vandalism is not revertable". This suggests me to add a [revert] link like on page histories, that with one click one can revert the last consecutive uploads from a user to the last revision.

But on the other hand, comment #0 states that the current situation "still leaves bogus "Restored to the first revision" entry in the image history." That's a completely new approach, very different from the revert on page histories: When you revert, the old edit is still shown on the page history. Do we like it to work different for file revisions?

I was tempted to suggest (probably on a new bug report, as alternative to the first approach) a way to revert "as if the upload we're going to revert didn't even happened". Basically, delete the last version in the file history and return the previous one as the current one. That way wouldn't pollute the file history with duplicate entries because of file reverts (which look weird when the intermediate uploads get deleted). That indeed would reduce the hassle of vandalism to 0 on file description pages. But on the other hand, that would make it inconsistent with how page histories work, the need to preserve history, etc. That's why I decided to not create such a feature request, but still I leave my idea here (with the pros and cons) in case someone thinks it's worth taking into account.

(In reply to Krinkle from comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > Fortunately the actions to achieve this level of vandalism are just as
> > > unreachable and unusable as the actions to undo them :P (otherwise commons
> > > would've been a mess)
> > 
> > This is not a fortune. The whole point of combating vandalism is that it
> > usually takes 1/100 of the time to revert it than to do it.
> 
> Sarcasm. I was referring to the fact that it's somewhat fortunate that it's
> almost as complicated to vandalize in this area then it is to undo it.
> Obviously undoing should be just as easy.

It could be far easier to perform vandalism on file history than reverting it. See bug 51383