To show up in the watchlist would require updating the timestamp of the image description page
itself.

leercontainer-bugzilla wrote:

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

rowan.collins wrote:

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

dbenbenn wrote:

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

Wiki.Melancholie wrote:

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

Wiki.Melancholie wrote:

(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

aleonard1 wrote:

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

Attached:

robchur wrote:

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

robchur wrote:

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.

robchur wrote:

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