Page MenuHomePhabricator

MediaWiki Xtools - "Top edits per namespace" creates fake attributions
Closed, DuplicatePublic

Description

I just checked Xtools and found in "Top edits per namespace" that 41 contributions to de:Schwarze are attributed to my account. I have never touched this article.
The error may be connected to the fact that "Schwarze" in de:WP was originally a translation from an imported article in en:WP and my alleged contributions are to the English article. My first username in de:WP was "Jossi"; I had to change this to "Jossi2" during SUL finalization, as "Jossi" had been in use before by a contributor in en:WP. I presume that the contributions the tool attributes to me came from this user who was blocked infinitely a long time ago. I definitely don't want to have contributions I never made attributed to me or to be identified as an infinitely blocked user.

Event Timeline

MusikAnimal added subscribers: Legoktm, MusikAnimal.

If you really didn't edit that article, than it was indeed probably an issue with the SUL finalization, and not with XTools.

See the dedicated Top Edits for your account on that article: https://xtools.wmflabs.org/topedits/de.wikipedia.org/Jossi2/0/Schwarze

Here are some diffs:

As you can these are clearly attributed to the "Jossi2" account. I'm not sure what to recommend... @Legoktm any ideas? I wonder if this is even fixable.

Thanks. I'm not sure how the SUL finalization or importing edits works, but for the record:

MariaDB [dewiki_p]> SELECT user_id FROM user WHERE user_name = 'Jossi2';
+---------+
| user_id |
+---------+
|   43038 |
+---------+
1 row in set (0.00 sec)

MariaDB [dewiki_p]> SELECT rev_user FROM revision WHERE rev_id = 83514028;
+----------+
| rev_user |
+----------+
|    43038 |
+----------+
1 row in set (0.00 sec)

where 83514028 is one of the example diffs.

On import, if the user name attached to the revision exists then rev_user is set to that user's user_id, whether it's really the "same" user or not. If the user name attached to the revision doesn't exist, the revision is created with the name but with rev_user set to 0. It's probably something of a toss-up whether other things consider it the same user or not (depending on whether those things look at rev_user or rev_user_text).

Renames don't seem to touch the rows with rev_user set to 0, so probably the SUL finalization renames didn't do it either.