Page MenuHomePhabricator

Edits miscounted as pending after transwiki import
Closed, ResolvedPublic

Description

Author: Complexwikipedia

Description:
User U translates some article [[de:foo]] from some other wiki, say [[fr:foo]]. The last version of the article is flagged. Some days later admin and editor A uses the transwiki import to import the history of [[fr:foo]] containing n>1 versions to [[de:foo]] for GFDL-reasons. The most recent version foo [[de:foo]] is newer than the most recent version of [[fr:foo]] and hence the current one after import. But, after import it is not marked as patrolled and some user is required to review n versions although the difflink ist empty as in http://de.wikipedia.org/w/index.php?title=Jules_Huret&diff=50492574&oldid=50492467 . The fact that one has to re-flag page although nothing has changed is somthing I consider a bug.

Apparently the confusing message to review n=28 versions is not due to the flagged revisions but some issue of transwiki import, but still very confusing in this context.


Version: unspecified
Severity: normal
URL: http://de.wikipedia.org/w/index.php?title=Spezial%3ALogbuch&type=&user=Complex&page=Jules+Huret&year=&month=-1

Details

Reference
bz15515

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:23 PM
bzimport set Reference to bz15515.

Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can
more so should deal with any other issues.

(In reply to comment #1)

Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can
more so should deal with any other issues.

If this becomes a problem, more query conditions can be added to the counter, but I'd rather avoid the extra load due to occasional and easily fixable issues due to import breakage.

(In reply to comment #2)

(In reply to comment #1)

Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can
more so should deal with any other issues.

If this becomes a problem, more query conditions can be added to the counter,
but I'd rather avoid the extra load due to occasional and easily fixable issues
due to import breakage.

Considering this now.

Other improvements have long since been (inadvertently) made such as callers using the function revsArePending(), which has no problems with this.

New tweaks on the way though.

OK, this situation shouldn't be problematic anymore. Whether the null revision with "(X revisions)" is autoreviewed or not, the FR UI should basically report things correctly.

MW core still miscounts "intermediate edits" of diffs for import cases...that's a separate issue.