Page MenuHomePhabricator

CheckUser "contributions" link should be a red link for non-existent accounts
Closed, ResolvedPublic

Description

In the "show users" action, when the user was one that was tried to be created and account creation was prevented by abusefilter, the "contributions" link should be a red link (as that user doesn't actually exist). Currently, it is a blue link.

Event Timeline

For what it's worth, there's previously been disagreement about whether a "contribs" link being red or blue is a feature. Some people think it violates the principle that "Special:Contributions/Foo" is an existent interface page and should naturally be blue. Others find the subtle behavior override (i.e., turning the "contribs" link red if the associated user has not edited or does not exist) to be convenient and welcome.

Okay, fine, we don't need to make it red anywhere, but can add a class that indicates this is a non-existent user!

Legoktm subscribed.

This behavior would match AbuseFilter, which also uses red contribs to indicate the user has no edits. Marking as good first task accordingly.

Hello @Huji. So for now the thing to do is to add a class that would "indicate that the user has no edits" right?. If so, could you please explain the steps for reproducing such situation? I am willing to take the task.

Yes, a class would be ideal.

The easiest set up I can recommend is this:

  • Install both CheckUser and AbuseFilter
  • Create a filter that does not allow account creation
  • Enable the filter, then try to create an account, it will log an event in AbuseLog
    • At this point you can disable the filter :)
  • Run a check on the IP you used to create the account (e.g. 127.0.0.1) it should show the AbuseLog entry, and the username it should show should belong to a non-existent account (the one whose creation was blocked). This account should have a class indicating it is non-existent

For a somewhat related idea, please see https://gerrit.wikimedia.org/r/#/c/370137/

Change 379811 had a related patch set uploaded (by African Hope; owner: African Hope):
[mediawiki/extensions/AbuseFilter@master] CheckUser "contributions" link should be a red link for non-existent accounts

https://gerrit.wikimedia.org/r/379811

@Huji , I followed the steps you proposed above and submitted a patch. A added the screenshots below as an illustration:

Before:

schreeshot_before.png (601×1 px, 89 KB)

After:

screenshot_after.png (540×1 px, 76 KB)

Change 380420 had a related patch set uploaded (by African Hope; owner: African Hope):
[mediawiki/extensions/CheckUser@master] CheckUser "contributions" link should be a red link for non-existent accounts

https://gerrit.wikimedia.org/r/380420

Change 379811 abandoned by African Hope:
CheckUser "contributions" link should be a red link for non-existent accounts

Reason:
The fix should have been applied on CheckUser extension instead. The link is here: https://gerrit.wikimedia.org/r/#/c/380420/

https://gerrit.wikimedia.org/r/379811

In Special:Log contribs are red in account creation entries where people have 0 edits, but all the accounts are existent of course. So I think there are at least 2 meanings to red contribs link.

Change 382780 had a related patch set uploaded (by Paladox; owner: Paladox):
[mediawiki/core@master] Make contrib link red if user does not exist (optional)

https://gerrit.wikimedia.org/r/382780

Change 382780 abandoned by Paladox:
Make contrib link red if user does not exist (optional)

https://gerrit.wikimedia.org/r/382780

Melos claimed this task.

Change 380420 merged by Huji:
[mediawiki/extensions/CheckUser@master] CheckUser "contributions" link should be a red link for non-existent accounts

https://gerrit.wikimedia.org/r/380420

We used to add CentralAuth to the MediaWiki:Checkuser-userlinks system message (see https://login.wikimedia.org/wiki/MediaWiki:Checkuser-userlinks) on loginwiki. This doesn't seem to be working anymore due to these changes.

Any idea how we can achieve this now? This is making the work of Stewards a lot harder.

Hmm, good question.

As a temporary remedy, I suggest creating a short gadget that adds the links on page load using JS. Should be fairly easy; if you cannot find someone to do it, remind me and I will create one.

As a longer term solution, we need to investigate why this change is preventing Checkuser-userlinks to take effect. And that may require a new task (or reopening this task)

I'm working on it and I'll send a patch for code review. I'll try to add new links as integration with global extensions.

Re-opening for now, awaiting a patch for Melos.

Change 384474 had a related patch set uploaded (by Melos; owner: Melos):
[mediawiki/extensions/CheckUser@master] Restore checkuser-userlinks when exist

https://gerrit.wikimedia.org/r/384474

While I'm working on something that show links for CentralAuth and GlobalBlocking I've sent a patch for "checkuser-userlink" message, so we can add the equivalent of "checkuser-userlinks-ip" also for registered users. Than we can close this bug and open another one as new feature request.

Change 384474 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Restore checkuser-userlinks when exist

https://gerrit.wikimedia.org/r/384474

Change 384509 had a related patch set uploaded (by MarcoAurelio; owner: Melos):
[mediawiki/extensions/CheckUser@wmf/1.31.0-wmf.3] Restore checkuser-userlinks when exist

https://gerrit.wikimedia.org/r/384509

Change 384509 merged by Hashar:
[mediawiki/extensions/CheckUser@wmf/1.31.0-wmf.3] Restore checkuser-userlinks when exist

https://gerrit.wikimedia.org/r/384509

I tested this on production and this gives:

(talk | contribs | block) (talk | contribs | block | CentralAuth) (Check)

while testing on mwdebug1001.

@Huji and @Melos please verify if this is really happening in your test environments, etc.

Regards.

Mentioned in SAL (#wikimedia-operations) [2017-10-16T23:49:28Z] <thcipriani@tin> Synchronized php-1.31.0-wmf.3/extensions/CheckUser/specials/SpecialCheckUser.php: SWAT: [[gerrit:384622|Revert "Revert "Restore checkuser-userlinks when exist""]] T170507 (duration: 00m 46s)