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

Fixed in r112843.

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

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).

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

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

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.

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).

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.

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.

(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.

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

(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.

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.

(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.

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

This bug confused another user, see T111605 (could be considered a duplicate).

In T36873#398155, @Platonides wrote:

This was caused by r100300 (intended to allow JOINing to get user_name) by no longer searching by username but by id.

Now visible at 99984c809e8cc726847f411cd4d3206692305e5b

I vote to revert this behavior, and make Special:Contributions search again by username (ie. rc_user_text).

+1

Viewing contributions through the API rather than the interface used to be a way to get around this bug; that is no longer the case.

Hein? T179831 hasn't been resolved yet either, without a patch even. Setting it as Resolved seems a bit premature.

Also, for example, this link should show far more than 194 edits:
https://en.wikipedia.org/w/index.php?title=Special:Contributions/conversion_script&offset=&limit=500&target=Conversion+script

And there's the User:0 problem (T182374).

In T36873#3860045, @Ebe123 wrote:

Hein? T179831 hasn't been resolved yet either, without a patch even. Setting it as Resolved seems a bit premature.

Patch is rMW96bd79b4a36a: Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames. That task isn't closed pending T181731: Run maintenance/cleanupUsersWithNoId.php on all wikis, which is pending T183019: Wikibase must not insert local recentchanges entries for nonexistent local users (days: 5) to be completely done.

In T36873#3860175, @Graham87 wrote:

Also, for example, this link should show far more than 194 edits:
https://en.wikipedia.org/w/index.php?title=Special:Contributions/conversion_script&offset=&limit=500&target=Conversion+script

[[User:Conversion script]] is an exception to the fix, since it's not a usable name the script didn't try to assign or prefix it. When T167246 happens it'll assign all the edits to the existing account.

It looks like dawiki and metawiki have such an account too. There may be other-named reserved accounts with the same situation, on those or other wikis. In general, either all edits will get assigned to the account when T167246 happens or the migration script will give me an error and I'll have to clean things up.