Last modified: 2011-01-25 01:35:38 UTC
As per discussion on the Wikitech-l mailinglist, it is obvious that vandalism by way of changing images is a big problem. Jimbo mentioned a conference image on [[George W. Bush]] being replaced by [[goatse.cx]]. See supplied link for the discussion. When a new image (or file) is uploaded to an already existing image it should show up in the watchlists of users watching the image description page (as suggested by Evan). This would serve the same "watching" function that is done with text today. I suggest that it shows up among the rest of the watchlist entries with the same line as other items, except that instead of "(diff)(hist)" you'd have "(view)" that would be a direct (Media:) link to the image (file). Example wathlist line: (view) . . Image:ClitorisNewLoc2.jpg; 17:17:05 . . 203.82.48.7 (Talk) (more pron - haha!) Alernatively it could be modeled more after "File history" entries on the image description page (Image:): (desc) . . ClitorisNewLoc2.jpg; 17:17:05 . . 203.82.48.7 (Talk) (more pron - haha!) Where "(desc)" ('imgdesc' message in Language.php) would lead to the description page (Image:ClitorisNewLoc2.jpg), and the filename would be a direct link ("Media:" type).
To show up in the watchlist would require updating the timestamp of the image description page itself.
(In reply to comment #1) > To show up in the watchlist would require updating the timestamp of the image description page > itself. Well, the description page _is_ infact changed, since a line is added to the "File history" section. I'm not into the technicalities of things, but I suppose what you describe is the easy way to do it. Would updating the timestamp also affect the history part of the description page?
Some additional thoughts on this: * Under 1.5, a new revision doesn't have to be linked to a new piece of text, so image uploads could cause genuine "null revisions" * To take that even further, we could avoid conflating this with the history of the description text by having a kind of "null page" in a special namespace which had no text, but whose revisions represented overwrite/reversion actions on the file itself. This might cause some craziness by violating assumptions about the structure of the database, though; it certainly feels a bit hacky... * Alternatively, could the watchlist check the upload log and interleave the results? * With the advent of the commons, however, this becomes a lot more awkward - bug 1394 discussed the need to *list* what projects use a commons image, this would require *contacting* them (since an image changing on commons means it changes everywhere else too!) But in a sense, that's a multi-project watchlist problem, which brings us back to single login...
It would be nice to have a null revision added to the image page, in exactly the same way as when moving an article. (For extra credit, the edit summary of the null revision could include the new version's file size, dimensions, and the upload summary.)
*** Bug 4803 has been marked as a duplicate of this bug. ***
(from bug 4803) > ...so I would suggest that actions like overwriting images and reverting to older revisions of an image be noted somehow in people's watchlists.
Poking 'upload' in the summary for easier searching
Since the watchlist is one of the two most powerful vandal fighting tools, the other being RC, this is an absolutely necessary tool. Poke the data and force a watchlist update or something, but until then, having watchlists on Commons is almost worthless.
Created attachment 2237 [details] Possible patch for issue This issue may be resolved with the attached patch, although it is entirely possible I'm using methods that are not available at this point in the code... (untested, please comment).
You need to save the revision. There is a problem using null revisions in this manner too, as I discovered when I added the one for page protection/unprotection operations; users attempting to roll back the revision will not encounter the expected behaviour, and it can cause unexpected problems. I've discussed the issue with Brion before; we need to be able to mark revisions as being unable to be rolled back for some reason.
(In reply to comment #10): > You need to save the revision. I see 2 possible alternative approaches on top of the one you are suggesting: 1) have Revision::newNullRevision take care of saving the revision. (which means that all uses of newNullRevision elsewhere have to be looked at and possibly changed). 2) change the rollback code and make it act as expected in this case. This is what newNullRevision promises to do (Revision.php:693): "Create a new null- revision for insertion into a page's history. This will not re-save the text, but simply refer to the text from the previous version." This does sound pretty efficient to me. Saving the rev with the same content just creates unnecessary overhead, IMO. P.s. I'm afraid solving this in real code this currently over my head...
No, you haven't inserted the null revision into the database. See example in Article::updateRestrictions(). You also have to update the page.page_latest and page.page_touched fields to ensure a continual relationship and to make sure various caches are invalidated.
*** Bug 7153 has been marked as a duplicate of this bug. ***
Done in filerepo changes. Uploads create a null edit.
(In reply to comment #14) > Done in filerepo changes. Uploads create a null edit. > It does not work reliable. It works on my local testwiki fine, but at least not on WMF wikis. Testcase: 1. [[de:Bild:Test watchlist.png]] uploaded today by [[de:User:Raymond]] 2. Overwritten today by same image by same user. The image history looks ok incl. a null edit but no entry on the wachtlist of [[de:User:Raymond]] Same effect on Commons today with [[commons:Image:Hohenzollernbrücke Köln - Einfahrt von Westen.jpg]].
Still the same behaviour Raimond described in comment 15. Tested on http://commons.wikimedia.org/wiki/Image:J.J._Burns_NSRW1-0009.jpg
It doesn't show up in the watchlist due to bug 5546. Currently, for operations where we create both log and edit history entries, only the log entry gets added to the recent changes queue. The log entry in RC records the special page title, not the target page title, so doesn't show up in watchlists. Per notes on bug 5546, there have been changes to the recentchanges table to add log information fields so that the records can be stored in a way that *will* show up on watchlists (putting the log info in [rc_log_type,rc_log_action], while recording the target page in [rc_namespace,rc_title]). When the logging code is updated to make use of this, it should start working as desired. I'll mark this as depending on bug 5546 for now...
Done with r32685 by Aaron Schulz.
