@wikitrent Sorry, this task is the last in a tail of tasks. You'll have to pick up a different task. The order is:

• T286661: Create framework for fetching on-wiki information [L]
• T270318: Block info in the popup [M]
• T270319: Contribs info in the popup [M]
• T286662: Display block and contribs info in popup and infobox [S] (this task)

@Niharika @phuedx A couple of few questions about which blocks we should count (I think related to work done in T270318 but that has already been resolved):

• We only count expired blocks as "past" blocks. Blocks which have been explicitly unblocked are not counted. For example, this IP has been blocked 3 times but only counts 1 past block (you'll need to open the network tab of your browser tools to see the response).
• We don't seem to count range blocks for "active" or "past" blocks. For example, this IP has a range block but IPInfo lists no active blocks.
• I couldn't get System Blocks to be counted (including $wgProxyList and $wgSoftBlockRanges, tested locally).
• Do we want to support GlobalBlocking?

Thanks for catching these, Dom. @Prtksxna also flagging this for you.

In T286662#7344013, @dom_walden wrote:

@Niharika @phuedx A couple of few questions about which blocks we should count (I think related to work done in T270318 but that has already been resolved):

• We only count expired blocks as "past" blocks. Blocks which have been explicitly unblocked are not counted. For example, this IP has been blocked 3 times but only counts 1 past block (you'll need to open the network tab of your browser tools to see the response).

I looked at the unblock log on enwiki. I see most frequent reasons for unblocks being - renamed from an auto-blocked username, incorrect blocks and successful repeals. I don't see a good reason to capture these in the past blocks. @Prtksxna would you agree?

• We don't seem to count range blocks for "active" or "past" blocks. For example, this IP has a range block but IPInfo lists no active blocks.
• I couldn't get System Blocks to be counted (including $wgProxyList and $wgSoftBlockRanges, tested locally).

I think we should capture both of these. @phuedx would you like me to make a new ticket for these?

• Do we want to support GlobalBlocking?

I believe we considered this but dropped it because of some concerns that might have come up when Thalia was here. I think it would be good to have this information, if possible. @phuedx what do you think on the technical feasibility?

In T286662#7350549, @Niharika wrote:

In T286662#7344013, @dom_walden wrote:

@Niharika @phuedx A couple of few questions about which blocks we should count (I think related to work done in T270318 but that has already been resolved):

• We only count expired blocks as "past" blocks. Blocks which have been explicitly unblocked are not counted. For example, this IP has been blocked 3 times but only counts 1 past block (you'll need to open the network tab of your browser tools to see the response).

I looked at the unblock log on enwiki. I see most frequent reasons for unblocks being - renamed from an auto-blocked username, incorrect blocks and successful repeals. I don't see a good reason to capture these in the past blocks. @Prtksxna would you agree?

At the moment, we fetch the number of past blocks (A) and unblocks (B) from the database and subtract the latter from the former (C = A - B). The more I think about this, I think it would be best to simply return the number of blocks and unblocks separately.

• We don't seem to count range blocks for "active" or "past" blocks. For example, this IP has a range block but IPInfo lists no active blocks.
• I couldn't get System Blocks to be counted (including $wgProxyList and $wgSoftBlockRanges, tested locally).

I think we should capture both of these. @phuedx would you like me to make a new ticket for these?

I'm happy to reopen the original ticket in order to work on those two points. Broadly, I think it's best to keep the conversation in one place whenever we can. This isn't a strong preference though – I'm happy to do whatever matches the AHT's regular workflow the closest.

• Do we want to support GlobalBlocking?

I believe we considered this but dropped it because of some concerns that might have come up when Thalia was here. I think it would be good to have this information, if possible. @phuedx what do you think on the technical feasibility?

I/we would have to investigate this (unless there's already a task about it?).

In T286662#7352278, @phuedx wrote:

In T286662#7350549, @Niharika wrote:

In T286662#7344013, @dom_walden wrote:

@Niharika @phuedx A couple of few questions about which blocks we should count (I think related to work done in T270318 but that has already been resolved):

• We only count expired blocks as "past" blocks. Blocks which have been explicitly unblocked are not counted. For example, this IP has been blocked 3 times but only counts 1 past block (you'll need to open the network tab of your browser tools to see the response).

I looked at the unblock log on enwiki. I see most frequent reasons for unblocks being - renamed from an auto-blocked username, incorrect blocks and successful repeals. I don't see a good reason to capture these in the past blocks. @Prtksxna would you agree?

At the moment, we fetch the number of past blocks (A) and unblocks (B) from the database and subtract the latter from the former (C = A - B). The more I think about this, I think it would be best to simply return the number of blocks and unblocks separately.

• We don't seem to count range blocks for "active" or "past" blocks. For example, this IP has a range block but IPInfo lists no active blocks.

We'd want the information in the popup and the box to be concise and still helpful. For this reason, I'd agree with @Niharika, we should just show the expired past blocks and not those that have been unblocked.

I really like @phuedx's idea of showing the numbers separately, but I think its more applicable for the IP range blocks. This way the patroller can know that the action was (possibly) not against this specific IP address.

What do you think of these variations (3 blocks, one was unblocked, one was a range block):

Details in brackets	Separate heading for range blocks	Minimal: Dont count unblocks, count range blocks
I like this, but worry if this is too much for a popup	I don't like this, it takes up too much space	This is good, but maybe hides important information

Change 730587 had a related patch set uploaded (by Wikitrent; author: Wikitrent):

[mediawiki/extensions/IPInfo@master] WIP: Display Block and Contrib info in popup

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

Perhaps this is a @Prtksxna question? This is what, with @wikitrent's patch, the pop up looks like right now. There are a few spacing issues but I wanted to ask specifically about the position of the disclaimer and if this was okay. It makes sense to keep disclaimers with the information they refer to but I'm not sure that's what's being conveyed through the popup atm.

In T286662#7425657, @STran wrote:

…There are a few spacing issues but I wanted to ask specifically about the position of the disclaimer and if this was okay. It makes sense to keep disclaimers with the information they refer to but I'm not sure that's what's being conveyed through the popup atm.

Since we are short on space in the popup we aren't planning to show the disclaimer there. We can remove it.

@imaigwilo You should be able to make sure you are getting the information that's on these screenshots when you test the code.

@Prtksxna Is there a mockup for displaying block and contribs information in the infobox? If not, perhaps we could do that separately, since the patch is doing quite a lot. We might also want a separate task for displaying the extra info like connectionType etc, since we aren't yet displaying that - see middle column in this screenshot with the patch applied:

In T286662#7466122, @Tchanders wrote:

@Prtksxna Is there a mockup for displaying block and contribs information in the infobox?

Would this work? Or do you mean designs where, for example, just on-wiki info is available?

There are some variations of the box that are linked from the task description (you might need to zoom and pan). Happy to add more if needed.

There are some variations of the box that are linked from the task description (you might need to zoom and pan). Happy to add more if needed.

Ah, I hadn't zoomed out far enough - thanks @Prtksxna

Am I right in thinking this task is just to add the blocks and contribs info? Before this task we're only showing the left column:

Seems to me it would be sensible to separate adding the non-blocks/contribs properties into a separate task, to break up the work, discuss any additional design questions separately and keep the commit history clean. What do you think?

@Tchanders Since we will likely need to update the text of the labels and add the actual information in a separate task, I would like to leave these changes in so the person with the new task can simply change the json data for the labels and spend more of their time on the data portion.

@wikitrent In the interest of separating concerns, I'd keep the work for displaying blocks/contribs (this task) distinct from adding the other properties

You can see these changes on Special:Contributions/ and Special:Log (popup).

@wikitrent: As I said in Slack, you'll need to rebase your change now that the changes for T295462: The infobox and popup should display properties from different sources in a given order [L] and T296665: Remove the source info/disclaimer from the popup. I'm happy to pair on this today or tomorrow, if you'd like.

@phuedx and @Tchanders I've gotten the rebase finished but there's some part that's not letting the data display. Can either of you point me to the file/function I'm missing?

Change 730587 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] Display Block and Contrib info in popup

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

IP info and IP popup for same IP address:
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&offset=&limit=250&action=history