Page MenuHomePhabricator

Special:Log/newusers should display blocks
Open, MediumPublic

Description

Often Special:Log/newusers is watched for abusive usernames. It'd be nice if blocks where already displayed in the log, as for now you have to click "block" just to find out someone else already blocked the user.

I think this should be doable by doing a left outer join ipblocks on ipb_user=log_user. Werdna suggested to add a ipb_expiry check just to make sure the information is up to date.

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:58 PM
bzimport set Reference to bz22705.

g33kdyoo wrote:

Let me see about this.

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

Since I'm not entirely sure whether there is a performance issue with this, I coded a newusers-tool that displays blocks and various other useful information:
http://toolserver.org/~coe/newusers.php?lang=meta&project=wikimedia&limit=100

rd232 wrote:

FYI, there is a Gadget that does this:

add

importScriptURI('http://ru.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markblocked.js&action=raw&ctype=text/javascript');

into Special:Mypage/skin.js

@Tobias, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

Aklapper subscribed.

@Tobias: I am resetting the assignee of this task because there have been no signs of progress lately (please correct me if I'm wrong).
Resetting the assignee avoids the impression that somebody is already working on fixing this task and it also allows anybody else to potentially work towards fixing this task.
Please claim this task again when you plan to fix this task (via 'Reassign / Claim' in the 'Action' dropdown menu) - it would be very welcome!
Thanks for your understanding and thanks for contributing to Wikimedia!!

EddieGP subscribed.

I'm sending in a patch which changes the "block" link to be named "change block" when the user is already blocked. Thus one won't need to click the link to get to know that the user is already blocked. If a more obvious styling is wanted that shouldn't be done in core but with local/personal js/css style changes IMO.

Change 344811 had a related patch set uploaded (by EddieGP):
[mediawiki/core@master] Show "change block" in userlinks for blocked users

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

My patch https://gerrit.wikimedia.org/r/#/c/344811/ was uploaded on Mar 26th. It had some issues (not excluding autoblocks), which were mentioned just after a few hours and resolved in a second patchset just a day later. Since then, Mar 27th it's rotting. For two and a half week (about every three days) I've rebased the patch and added a few more reviewers each time. I've looked into git blame who edited the same file before and looked at the list of maintainers on mw.org. Honestly, I've spent more time trying to find someone who might review this than looking where and how to solve the issue and writing the code. On Apr 16th I've recieved feedback from Legoktm (who also mentioned the autoblock thing a few minutes after PS1 and the only one who added any comments on the patch until now):

Code-wise this seems fine, but I'm concerned about slow this is going to be if it has to individually look up 50 different users block status...

My answer (from Apr 18th) was:

Or even 500... so, how could we improve this? I honestly didn't think about it, but it seems that'd be a lot of load (for little benefit). I don't know if there's any way of testing how this harms performance though.

Since then, there was no more activity on that patch. I don't know if there is any solution to this which doesn't harm performance too bad. If there is, I neither know if my patch is such a solution nor how to check whether it is. If there is another way of solving this problem which isn't as bad for performance as my current approach is, I don't which way that is. That's for the technical side.

The social one is: I don't know who to add as a reviewer who might know these things. And given that only one person (thanks to Legoktm) dared to review this within a timespan longer than a month, I don't know if anybody gives a sh** at all.

As I have absolutely no clue what to do to bring this forward, I'll leave this comment here in the hope that anybody reads it and we can find some solution on this. And yes, for me one solution would be that somebody who knows about that stuff says that this is impossible because of performance. The only thing I actually don't know how to work with is no feedback at all. Hence, if there is no progress on this until the end of this month, May 31th, I'm going to assume that at least one of the following statements is true:

  • Nobody wants this feature.
  • It is impossible to do this for performance reasons.

The logical consequence would be to abandon my patch and close this task as "Declined".

I think it may be required to block this feature on the ability to do batch lookups for blocks, and then to ensure that any (in)direct callers of Linker::blockLink() that will do so for many different users (such as SpecialLog, SpecialRecentchanges, HistoryAction, ..) first initialise this batch lookup so that the in-process cache for them is already warmed up by the time Linker::blockLink is called.

We already do this in various places for title information (e.g. page exists red links, redirects etc.) using the LinkCache and LinkBatch classes, which Title checks first, which means pages that create a lot of pages can first use LinkBatch to populate LinkCache.

We also have UserArray which does something similar to User. And while there is no "User cache" class, the User class does cache information in object cache, which includes an in-process HashBagOStuff thanks to the pcTTL setting pass to WANObjectCache there.

However we don't yet batch lookup or caching for Block as far as I can see.

@Legoktm @tstarling Any ideas? Seems like https://gerrit.wikimedia.org/r/#/c/310306/ might be relevant here if we want to generalise batching and caching more generally for non-title information.

I don't think I'll be able to bring this forward (just don't know enought about the necessary changes to make batch-lookups for blocks possible), so I'm removing myself here. Feel free to amend my patch (https://gerrit.wikimedia.org/r/#/c/344811/) :-)

Change 344811 abandoned by EddieGP:
Show "change block" in userlinks for blocked users

Reason:
Per performance concerns. Feel free to restore and amend once there is a solution to that problem.

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