Last modified: 2014-03-24 15:27:42 UTC
From https://commons.wikimedia.org/wiki/Commons:Village_pump#OAuth_Flickr2Commons_Flickrreview_tags ( https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=119681006#OAuth_Flickr2Commons_Flickrreview_tags ) When uploading an image via oAuth, the log entry gets an edit tag ( https://commons.wikimedia.org/w/index.php?title=Special%3ALog&type=upload&user=&page=File%3AChristopher+Lydon.jpg&year=&month=-1&tagfilter=&hide_thanks_log=1 ), but the dummy edit in the file page's history ( https://commons.wikimedia.org/w/index.php?title=File:Christopher_Lydon.jpg&oldid=0&diff=119681891 ) does not. Expected behaviour would be that they both get tagged. Perhaps something to do with the dummy edit being hidden from RC (?)
(In reply to Bawolff (Brian Wolff) from comment #0) > Perhaps something to do with the dummy edit being hidden from RC (?) That is very likely the case: OAuth uses the RecentChange_save hook to tag things (see MWOAuthAPISetup::onRecentChange_save), so if that hook doesn't get called for the dummy edit then OAuth won't tag it. The next step here would be to identify (or add) a hook that is called when these dummy edits are created but not saved as recent changes, so we can hook that too. I'm not terribly familiar with the uploading code path, so if you are and can point to where the dummy edit gets created that would be helpful. Otherwise I'll try to remember to track it down later.[1] [1]: (although what'll probably happen then is that I'll forget until Andre pings us in a few months asking if there's any progress)
It's created with a line like: $status = $wikiPage->doEditContent( $content, $comment, EDIT_NEW | EDIT_SUPPRESS_RC, false, $user ); in LocalFile::recordUpload2. (A slightly different but similar code path is used for re-uploads) Could perhaps add $flags to NewRevisionFromEditComplete hook.
Thanks for that, now I see where to look in the code. NewRevisionFromEditComplete looks like it'd probably be a good hook to use since it seems to be called from a few other relevant code paths too that directly insert the revision. Unfortunately, it also looks like you're right that we'd need to add some sort of flagging to the hook (although that seems a bit "ugh" to me considering every other caller would probably have to fake it), or else fix ChangeTags::addTags so that calling ChangeTags::addTags( $tags, null, $rev_id, null ) then ChangeTags::addTags( $tags, $rc_id, $rev_id, $log_id ) will update the change_tag table with the $rc_id and $log_id instead of just completely ignoring the second call.
