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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
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