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.
|Open||None||T177793 Make links to non-existent accounts visually distinctive in CheckUser|
|Resolved||Melos||T170507 CheckUser "contributions" link should be a red link for non-existent accounts|
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.
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/
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.
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)
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.