Page MenuHomePhabricator

Links to blocked/locked user accounts should have a class indicating so
Closed, DeclinedPublic3 Story Points

Description

In several places (e.g. AbuseLogs, CheckUser logs, user lists, etc.) it is beneficial to have an easy way to identify accounts that are locally and/or globally locked or blocked.

Let's make sure our Linker functions add a class to links to User pages if they belong to users that are currently locked/blocked.

This will make T169461 obsolete.

Event Timeline

Huji created this task.Aug 3 2017, 12:50 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 3 2017, 12:50 AM
Huji claimed this task.Aug 3 2017, 12:51 AM
Huji updated the task description. (Show Details)

Change 370137 had a related patch set uploaded (by Huji; owner: Huji):
[mediawiki/core@master] Links to blocked/locked user accounts should have a class indicating so

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

Huji added a comment.Aug 4 2017, 2:31 AM

The output using the above patch:

Jdforrester-WMF added a subscriber: Jdforrester-WMF.

This mostly feels like a blocker to T169839: Strikethrough blocked/locked accounts anywhere they are displayed specifically, right? CSS class allows different visual treatments (with concomitant discussion about accessibility in use of colours and contrast, italics and how they don't work for pictographic languages, visual confusion, and so on).

Huji added a comment.EditedAug 4 2017, 6:36 PM

Yes. And I think T169839 should be merged into T172554, because the former is only about AbuseFilter, and the latter is about every use case.

Johan added a subscriber: Johan.Aug 9 2017, 3:42 PM

Any idea of what the timeline for this would be (if possible to say)?

We already have a patch, but @Anomie and @Legoktm have suggested that (a) it should be modified to distinguish locks and blocks, and (b) it should probably use a cache of sorts.

I know how to do the former, but I am having difficulty setting up a test environment for it. As for (b), I actually don't have a firm plan, and will most likely end up copying from our other caching mechanisms. So no, no firm timeline is available.

Huji added a comment.Aug 11 2017, 12:47 PM

I posted a set of questions I need help with in https://gist.github.com/Huji/a41e3d59ac4c43f245083024dbf36203

Once I receive help with those, I can do part (a)

I posted a set of questions I need help with in https://gist.github.com/Huji/a41e3d59ac4c43f245083024dbf36203

Ugh. It'd probably have been easier to reply to if you had done that as a comment (possibly with pastes for the long config snippets) here in Phab.

When I logged out of both wikis, and then logged into metawiki, it did not automatically log me into enwiki. What setting am I missing?

Probably $wgCentralAuthAutoLoginWikis and $wgCentralAuthLoginWiki.

At this point I tried to create an account on enwiki. Then I went to metawiki and tried to block Blocked@enwiki while logged in as Admin (noticed that Admin is a steward there, and therefore has the rights to block users on other wikis). Yet I got the following error message: There is no user by the name "Blocked@enwiki". Check your spelling.
What setting am I missing?

I don't know about that one. Does it even work that way on the real metawiki? Or is the "@enwiki" just for user rights rather than blocking?

I then went back to metawiki, and locked the User:Locked. I verified that the lock works (i.e. User:Locked could no more log in). Then I tried similar code:
User:newFormId(2)->getBlocked()
But this returns null as the output.
How do I get the lock status of an account?

User:newFormId(2)->getLocked()

How do I make a filter on metawiki a global filter?

I haven't tried it myself, but comparing to WMF's configuration: In this bit of your configuration

if ( $wikiId = 'metawiki' ) {
  $wgAbuseFilterCentralDB = true;
}

that should be $wgAbuseFilterIsCentral, not $wgAbuseFilterCentralDB. I think that will make the "global" checkbox show up when editing the filter on metawiki.

When I changed it to the latter and hit the Update button, I got an error message as follows. What am I doing wrong?

Same as above, $wgAbuseFilterCentralDB is set wrong on your metawiki.

Huji added a comment.EditedAug 16 2017, 10:18 AM

How do I get the lock status of an account?

User:newFormId(2)->getLocked()

No such function exists?

PS: I found a solution. You can get an instance of the CentralAuthUser and check if canAuthenticate() is equal to "locked".

Huji added a comment.Aug 16 2017, 11:00 AM

I haven't tried it myself, but comparing to WMF's configuration: In this bit of your configuration

if ( $wikiId = 'metawiki' ) {
  $wgAbuseFilterCentralDB = true;
}

that should be $wgAbuseFilterIsCentral, not $wgAbuseFilterCentralDB. I think that will make the "global" checkbox show up when editing the filter on metawiki.

When I changed it to the latter and hit the Update button, I got an error message as follows. What am I doing wrong?

Same as above, $wgAbuseFilterCentralDB is set wrong on your metawiki.

This does make the global checkbox appear, and the second problem is also resolved. But when I go to Special:AbuseFilter on the enwiki I do not see the filter listed, and edits on enwiki don't trigger the global filter either. There is one more bit missing. I updated the gist to show what my latest config looks like.

How do I get the lock status of an account?

User:newFormId(2)->getLocked()

No such function exists?

My mistake. The method is named isLocked(), not getLocked().

TBolliger set the point value for this task to 3.Sep 26 2017, 6:24 PM
TBolliger added a subscriber: TBolliger.

Need to check that this behaves well with link caching.

Huji added a comment.Oct 11 2017, 7:52 PM

Excellent point. If you tell me more, I might be able to do the check as well.

Seems like the patch is waiting for some answer of @Tgr.

Huji added a comment.Jan 2 2018, 12:56 AM

The answer to @Tgr is now provided on the patch.

Patch says "it should be ready to merge now" for almost one month, what is happening here?

Huji closed this task as Declined.Mar 6 2018, 12:22 AM

Per T188888, harms (in term of server-side efficiency and/or code refactoring) outweight the benefits.

Change 370137 abandoned by Huji:
Links to blocked/locked users should have a class indicating so

Reason:
Task declined

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

Teles added a subscriber: Teles.Feb 8 2019, 8:40 PM