Special:Contributions no longer shows contributions by name - problems listing contributions stored with user ID = 0
OpenPublic

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz34873.
TheDJ created this task.Via LegacyMar 1 2012, 9:27 PM
MarkAHershberger added a comment.Via ConduitMar 1 2012, 9:30 PM

deployment has happened but we want this fixed for the tarball.

aaron added a comment.Via ConduitMar 1 2012, 10:10 PM

Fixed in r112843.

Graham87 added a comment.Via ConduitMar 2 2012, 7:01 AM

I was the one who originally noted this bug at the technical village pump:
http://en.wikipedia.org/wiki/Wikipedia:Vpt#Contributions_lists_for_truncated_IP_addresses_don.27t_work_anymore

I did some more testing today and discovered more cases where the contributions are no longer listed properly, because the user's edits are attached to more than one userid in the database. This usually happens because the edits were imported from the UseModWiki database in September 2002 under user ID 0 (because the accounts didn't exist then), and then other edits were imported from the Nostalgia Wikipedia later or the account was compromised. Compare this:
http://en.wikipedia.org/wiki/Special:Contributions/LarrySanger

with this:
http://nostalgia.wikipedia.org/wiki/Special:Contributions/LarrySanger

Also, the edits that are assigned to the username "0" from 2002 don't show up with Special:Contributions either, presumably because they are listed under several userids:
http://en.wikipedia.org/wiki/User:0
http://en.wikipedia.org/wiki/special:Contributions/0

The same is true of Conversion scrip:
http://en.wikipedia.org/wiki/Special:Contributions/conversion_script

This is also true of the truncated IP address 11.105, which has many many edits due to a bug in the first version of MediaWiki (I created an account under that name to avoid impersonation):
http://en.wikipedia.org/wiki/Special:Contributions/11.105

Platonides added a comment.Via ConduitJul 14 2012, 6:19 PM

This was caused by r100300 (intended to allow JOINing to get user_name) by no longer searching by username but by id.
I vote to revert this behavior, and make Special:Contributions search again by username (ie. rc_user_text).

Platonides added a comment.Via ConduitJul 14 2012, 6:25 PM

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

Platonides added a comment.Via ConduitJul 14 2012, 6:49 PM

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

Krinkle added a comment.Via ConduitJul 21 2012, 7:50 PM

It appears to be fixed now.

https://en.wikipedia.org/wiki/Special:Contributions/62.253.64.xxx shows contributions.

And when testing locally on the latest master, edits by maintenance scripts (user id 0) also show up properly.

Platonides added a comment.Via ConduitJul 21 2012, 8:38 PM

It's not, see for intance http://nl.wiktionary.org/wiki/Speciaal:Bijdragen/Metr%C3%B3nomo where edits do exist: http://nl.wiktionary.org/w/index.php?diff=prev&oldid=1070120

You're seeing a workaround, where if there isn't an account with that name, searches by text, but if the account exists, it searches by user id.
Which leads to odd situations such as the contributions you were seeing magically disappear when you login for the first time (see bug 37735).

aaron added a comment.Via ConduitJul 21 2012, 8:45 PM

We should really fix the DB entries. If the edits are by user X, they should be recorded as such. Maybe the import/user logic could be changed to handles this better, though it's bit tricky.

Krinkle added a comment.Via ConduitJul 21 2012, 8:55 PM

The problem is that when importing things from a different wiki, the username can be someone else. So that's why (afaik) the import system specifically does not tie edits to a user id.

aaron added a comment.Via ConduitJul 22 2012, 12:59 AM

(In reply to comment #10)

The problem is that when importing things from a different wiki, the username
can be someone else. So that's why (afaik) the import system specifically does
not tie edits to a user id.

Right, and so why should would list the contribs of both users under the one name? Either we go all the way or don't. I'd prefer not attributing things to someone unless it is that person for sure.

Such rows could perhaps be flagged and displayed slightly differently in history/RC links. If the contribs link had an extra parameter it could show header or footer about the edits being imported and list by rev_user_text = X.

Krinkle added a comment.Via ConduitJul 22 2012, 1:19 AM

.. and not to mention how to deal with imports from different wikis :D

Graham87 added a comment.Via ConduitJul 22 2012, 2:20 AM

(In reply to comment #10)

The problem is that when importing things from a different wiki, the username
can be someone else. So that's why (afaik) the import system specifically does
not tie edits to a user id.

When an edit is imported using Special:Import, it is tied to a user ID if there is an account under that name. If not, it's imported as user ID 0.

Graham87 added a comment.Via ConduitJul 22 2012, 2:22 AM

And the same thing happened with the script that imported UseModWiki edits from September 2002, except many of those accounts had not yet been created, hence many of them are under user ID 0.

Platonides added a comment.Via ConduitJul 22 2012, 12:25 PM

(In reply to comment #11)

Right, and so why should would list the contribs of both users under the one
name? Either we go all the way or don't. I'd prefer not attributing things to
someone unless it is that person for sure.

Except that it is usually the same person.

When they ask for contributions of Foo, we should show every edit we are attributing to Foo. Doing otherwise is inconsistent.

I'm not opposed to the proposal of annotating them in an special way. We could for instance show that it it imported, and even from which page, storing it at change_tag. But they should still be shown in Special:Contributions.

Graham87 added a comment.Via ConduitMar 29 2013, 11:14 PM
  • Bug 45177 has been marked as a duplicate of this bug. ***
Graham87 added a project: Regression.Via WebDec 5 2014, 3:33 PM
He7d3r edited the task description. (Show Details)Via WebMar 20 2015, 3:29 PM
He7d3r set Security to None.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.