Last modified: 2010-12-14 17:43:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17515, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15515 - Edits miscounted as pending after transwiki import
Edits miscounted as pending after transwiki import
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Aaron Schulz
http://de.wikipedia.org/w/index.php?t...
:
Depends on:
Blocks: 26334
  Show dependency treegraph
 
Reported: 2008-09-07 22:43 UTC by Complex
Modified: 2010-12-14 17:43 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Complex 2008-09-07 22:43:17 UTC
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.
Comment 1 Aaron Schulz 2008-09-07 23:33:17 UTC
Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can
more so should deal with any other issues.
Comment 2 Aaron Schulz 2008-09-07 23:44:02 UTC
(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.
Comment 3 Aaron Schulz 2010-07-11 07:22:24 UTC
(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.
Comment 4 Aaron Schulz 2010-12-08 04:57:01 UTC
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.
Comment 5 Aaron Schulz 2010-12-08 05:18:33 UTC
Tweaks made in r78044.
Comment 6 Aaron Schulz 2010-12-08 07:34:26 UTC
More in 78051.
Comment 7 Aaron Schulz 2010-12-08 19:42:16 UTC
Also in r78092.
Comment 8 Aaron Schulz 2010-12-08 19:54:55 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links