@Niharika Do we want IPInfo buttons next to every IP address on this page?

Yes, please. There has been a related request here: T309366: Investigate: IP info not shown when all IP's edits are deleted

CC @Prtksxna

The rows where the IPInfo icon does not appear next to IP addresses also do a jump (the opposite of this bug T271486).

I'm looking at this example, which should hopefully be readily searchable:

The problem appears to be twofold:

1. There is no rev id associated with the edit on the current wiki. The edit appears to only exist on the wiki the data was imported from:

https://wikidata.beta.wmflabs.org/wiki/Special:Contributions/93.227.187.52 (edit exists) vs https://en.wikipedia.beta.wmflabs.org/wiki/Special:Contributions/93.227.187.52 (no edits)

2. We don't consider these IPs to be anonymous. To compare, we use the existence of the .mw-anonuserlink class to find anonymous edits and pull the rev id from there:

<a href="/wiki/Special:Contributions/99.107.93.219" class="mw-userlink mw-anonuserlink ext-ipinfo-anonuserlink-loaded" title="Special:Contributions/99.107.93.219"><bdi>99.107.93.219</bdi></a>

and the relevant api call: https://en.wikipedia.beta.wmflabs.org/w/rest.php/ipinfo/v0/revision/552620?dataContext=popup

vs an imported wikidata entry:

<a class="extiw" href="https://wikidata.beta.wmflabs.org/wiki/Special:Contributions/93.227.187.52">93.227.187.52</a>

so we'd never check for a rev id in any case.

I did notice that IP Info is installed on the wikidata.beta server and trying to hit https://wikidata.beta.wmflabs.org/w/rest.php/ipinfo/v0/revision/1305332?dataContext=popup gives me a 403 error which is expected, since I don't have permission on that wiki.

Additionally, I noticed when I tried importing edits to wiki pages, the edits were successfully imported as revisions I could look up the IPs for. This seems to be an issue that arises with how we manage these other data types (in that we don't duplicate the change but instead appear to maintain a reference to the original change). I'm not sure there's a "best practice" way to resolve this, given the ownership of data is split across 2 wikis without doing something invasive further upstream and with the potential for large side effects. There's possibly a hacky way around this and it could look like:

1. Check against .extiw and other "external" changes and see if the user is an IP.
2. If it is, get the rev id (can be found in the diff link eg. https://wikidata.beta.wmflabs.org/w/index.php?title=Special%3AEntityPage%2FQ11&curid=24&diff=1305332&oldid=1305330 gets the rev id 1305332).
3. Try to call the ipinfo api from the originating server.

3 probably requires another endpoint that manages cross-wiki calls specifically. I don't know enough about CentralAuth to know if we can do this from the backend and check against the user's permissions on another wiki and then call that wiki's api without hitting the CORS problems we probably would otherwise. cc @Tchanders for a second opinion on if this concept is even feasible? 🙇

Thanks @STran. I think it should be doable - see https://www.mediawiki.org/wiki/Extension:CentralAuth/API and https://www.mediawiki.org/wiki/Manual:CORS#Using_mediawiki.ForeignApi

This approach makes sense to me. Certainly being able to look up info from another wiki would be helpful, since @Prtksxna and @Niharika are looking at other feature requests that might make use of this (e.g. showing IPInfo if an IP has contributions on another wiki but not the current one).

Are we likely to need a separate solution for StructuredDiscussions pages and changes to categories?

It looks like each case will require its own handling:

WikiData

I summarized a possible solution above but didn't go into depth regarding actually making the call (which I'll put off for a little longer). We could also make an upstream change here where we add the rev id as a data attribute (eg. data-extrevid) which would make it less hacky to get that id and call on it.

use of .extiw; possibly not unique https://codesearch.wmcloud.org/search/?q=extiw&i=nope&files=php&excludeFiles=&repos=
Linker's treatment of "known links" which is I believe the use case we're targeting and where we can add the data attribute https://gerrit.wikimedia.org/g/mediawiki/core/+/b4eaf5e3046822b45f4f6137a6fc7847668e4509/includes/linker/LinkRenderer.php#234

StructuredDiscussions (formerly Flow)

Some reference material:
general documentation https://www.mediawiki.org/wiki/Structured_Discussions
relevant logline handling file https://gerrit.wikimedia.org/g/mediawiki/extensions/Flow/+/1c1fc25e70095b8c2ee9523c553ca5b2ec648df8/includes/Hooks.php
revision link generator: https://gerrit.wikimedia.org/g/mediawiki/extensions/Flow/+/1c1fc25e70095b8c2ee9523c553ca5b2ec648df8/includes/UrlGenerator.php#139

I made a comment on a structured discussion page from an IP: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Contributions/198.54.131.102
This IP also has a standard contribution to compare against as well. As you can see, the structured discussion edit is considered a .mw-flow-contribution and uses a different schema (the concept of the topic, post, and rev ids) to track edits:

https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Topic:X00pgg5am1jchzoe&topic_postId=x00ph3036kcwakm6&topic_revId=x00ph3036kcwakm6&action=single-view

I suspect, but wasn't able to locally confirm (because StructuredDiscussions is not compatible with sqlite which is what I'm running atm), that we could either query through Flow's own APIs (https://www.mediawiki.org/wiki/Flow/Architecture/API) or the db (Flow uses its own db) directly for the ip given a postId. Reading through the docs, it doesn't look like Flow is built to support (but also doesn't explicitly prevent) other parties calling its API:

Flow has an extensive API that's heavily exercised by one client – the JavaScript on Flow board

and additional work may be required if we want to use what's currently available (I think we'll want post id and not just topic id):

includes/UrlGenerator.php can fabricate all kinds of URLs. May API queries return these URLs in the links object for each topic and post, but clients can't create their own. Given a topic UUID you can simply make a title object for Topic:UUID but fabricating a link to a post or a link to view a topic in context on a board requires knowledge of Flow internals.

The check on Special:Contributions for a rev id would have to be modified to also check for .mw-flow-contribution as well so that it doesn't prematurely throw the "no revision" error.

Categories

I'm not sure I understand the issue with Category edits @dom_walden. I made an edit to a category page and can see the popup for IPs: https://en.wikipedia.beta.wmflabs.org/wiki/Category:AnotherTest

tl;dr - There are probably a lot of design considerations on top of making calls to external wikis that should probably be considered before we attempt any technical work but broadly, it should be possible to make the API call. This would resolve retrieving the data for WikiData IPs. StructuredDiscussions should be located on-wiki but since the information is in its own database, it will also require its own handler. I would recommend splitting these into their own tickets if we choose to move forward with the work.

In T310813#8103773, @STran wrote:

I'm not sure I understand the issue with Category edits @dom_walden. I made an edit to a category page and can see the popup for IPs: https://en.wikipedia.beta.wmflabs.org/wiki/Category:AnotherTest

@STran The issue comes when adding/removing a page to/from a category. In the below example I added the article "PageTriageBugTest1" to the category "Foobar". The edit I made to the article has an IPInfo button but not the category change.

For completeness: here's a discussion from early on in the project, which covers why we don't want to provide an endpoint for querying any IP address: T260821#6453709. The linked comment also proposes a solution where we do allow sending the IP address without a log ID or rev ID, but it has probably too large a performance cost.

Thanks for posting the screenshot, Dom! I had some trouble reproducing this consistently so I'd appreciate it if someone can suggest more reliable repro steps 🙏 I added a category using these instructions: https://www.mediawiki.org/wiki/Help:Categories but more often than not, it would treat it as a standard revision. I did manage to make it occur once or twice and it was helpful for me to enable the "Category changes" filter to see them. That comes from "enhanced recent changes" which (I think?) is enabled via these instructions: https://www.mediawiki.org/wiki/Help:New_filters_for_edit_review

From what I can tell, category changes are considered revisions as well (but it seems to generate its own revision row). Given that, I was able to get a version working with this diff:

diff --git a/includes/changes/ChangesList.php b/includes/changes/ChangesList.php
index 1d5d76e5e1..f148824350 100644
--- a/includes/changes/ChangesList.php
+++ b/includes/changes/ChangesList.php
@@ -970,6 +970,8 @@ class ChangesList extends ContextSource {
                                $attrs['data-mw-logaction'] =
                                        $rc->mAttribs['rc_log_type'] . '/' . $rc->mAttribs['rc_log_action'];
                                break;
+                       case RecentChange::SRC_CATEGORIZE:
+                               $attrs['data-mw-revid'] = $rc->mAttribs['rc_this_oldid'];
+                               break;
                }
 
                $attrs[ 'data-mw-ts' ] = $rc->getAttribute( 'rc_timestamp' );

If you look at the ChangesList.php, you may recognize the data-mw-revid, which is set via $attrs['data-mw-revid'] = $rc->mAttribs['rc_this_oldid'];. The oldid comes from the RecentChange class.

This seems safe enough so I'll put up a patch for review but I'm not attached to it if anyone sees anything I've missed.

Change 817928 had a related patch set uploaded (by STran; author: STran):

[mediawiki/core@master] Add revid to category changes

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

To summarize, since I know it's spread across a few posts:

tl;dr - each type of log line will require its own handling.

Category changes:
Seems to be resolvable by treating it like any other revision. See https://gerrit.wikimedia.org/r/c/mediawiki/core/+/817928

Wikidata:
Technically feasible but will require handling of API calls to third-party wikis. Should be resolved as part of a larger initiative to support cross-wiki data (eg. global contribution counts) since those calls should be made through the same base mechanism. I suggest we split this off into its own task since it'll also require product/design input (eg. access to this information cross-wiki).

StructuredDiscussions:
Technically feasible but will require additional investigation since StructuredDiscussions/Flow uses its own database and can't be treated like other revisions. I suggest this also get split into its own task.

cc @Niharika @Prtksxna The calls to third-party wikis we need for WikiData should especially get some product/design eyes on it before anything technical happens (For instance, what do we display if the user doesn't have rights on the third party wiki where they want the data? etc etc). Is this work we want to take on?

cc @Niharika StructuredDiscussions might be a big lift to support given that it's an opt-in extension that appears to not be taking any more opt-ins. See https://www.mediawiki.org/wiki/Structured_Discussions/Wikis and https://www.mediawiki.org/wiki/Structured_Discussions/Request_Structured_Discussions_on_a_page. It won't cost us anything for me to write up the ticket, but would you like it prioritized?

In T310813#8110839, @STran wrote:

Thanks for posting the screenshot, Dom! I had some trouble reproducing this consistently so I'd appreciate it if someone can suggest more reliable repro steps 🙏 I added a category using these instructions: https://www.mediawiki.org/wiki/Help:Categories but more often than not, it would treat it as a standard revision. I did manage to make it occur once or twice and it was helpful for me to enable the "Category changes" filter to see them. That comes from "enhanced recent changes" which (I think?) is enabled via these instructions: https://www.mediawiki.org/wiki/Help:New_filters_for_edit_review

I notice in my LocalSettings.php I have $wgRCWatchCategoryMembership = true; so maybe that does the trick.

I'm a little confused, I don't think I understand our findings here:

• The info icon doesn't show up when there is no rev ID associated with a change line. Does this only happen for StructuredDiscussions pages, changes to Categories and changes to WikiData items? Or are there more types of change lines that have this issue?
• Changes to Wikidata items: Where is this a problem? I can see the info icon on Wikidata. Does it only happen on the WMF labs wikidata because of the way things are imported there (as @STran mentioned)?

In T310813#8094704, @Tchanders wrote:

This approach makes sense to me. Certainly being able to look up info from another wiki would be helpful, since @Prtksxna and @Niharika are looking at other feature requests that might make use of this (e.g. showing IPInfo if an IP has contributions on another wiki but not the current one).

Yep, it'll be helpful for CheckUsers and Stewards to be able to look-up IPs that have made edits on a different wiki altogether. I am guessing that'll be on the Special:Contributions page and not through the icon. The way the receive reports has links to the contribs pages of IPs and they'd click that on their home wiki expecting to see IP info. There'd be other design considerations too, but broadly speaking this would be their process.

The info icon doesn't show up when there is no rev ID associated with a change line. Does this only happen for StructuredDiscussions pages, changes to Categories and changes to WikiData items? Or are there more types of change lines that have this issue?

There may be other types but I don't know them. It's looking like any type that's not a "standard" revision will require its own handling. cc @dom_walden if you know of any other types?

Changes to Wikidata items: Where is this a problem? I can see the info icon on Wikidata. Does it only happen on the WMF labs wikidata because of the way things are imported there (as @STran mentioned)?

Yes and it'll happen for any other imports that don't duplicate the revision onto the receiving wiki. The Wikidata edits are considered "external" to the receiving wiki so while IPInfo on Wikidata can recognize the revisions as such, IPInfo on a wiki where Wikidata was imported has no such handling.

In T310813#8126722, @STran wrote:

Yes and it'll happen for any other imports that don't duplicate the revision onto the receiving wiki. The Wikidata edits are considered "external" to the receiving wiki so while IPInfo on Wikidata can recognize the revisions as such, IPInfo on a wiki where Wikidata was imported has no such handling.

So, is it safe to say that the Wikidata issue wont ever happen on our production wikis? Is there any way such edits can show up on RecentChanges on our (production) wikis?

The ability to look-up IP info for edits made on different wikis is still useful. As I mentioned in the previous comment the ability to look-up IPs that have made edits on a different wiki would be helpful on Special:Contribs. Does that change anything in how we approach this problem?

In T310813#8126722, @STran wrote:

The info icon doesn't show up when there is no rev ID associated with a change line. Does this only happen for StructuredDiscussions pages, changes to Categories and changes to WikiData items? Or are there more types of change lines that have this issue?

There may be other types but I don't know them. It's looking like any type that's not a "standard" revision will require its own handling. cc @dom_walden if you know of any other types?

I don't know. I haven't found any other types so far.

I used quarry to run the SQL query SELECT * FROM recentchanges GROUP BY rc_source; against enwiki's database. It only returned 5 entries corresponding to the rc_source values of mw.edit, mw.log, mw.new, mw.categorize and wb. flow was missing for some reason.

Change 817928 merged by jenkins-bot:

[mediawiki/core@master] Add revid to category changes

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

Calling this investigation done:

• RecentChanges case's patch has been merged
• StructuredData case is tracked at T309941: IPInfo refuses to show IP informations if IP made only Flow modifications
• WIkiData case is tracked at T315528: Add IPInfo popup for imported WikiData revisions

I now see the IPInfo icon appearing for category changes on RC.

For example, look at https://en.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?userExpLevel=unregistered&hidepageedits=1&hidenewpages=1&hideWikibase=1&hidelog=1&limit=500&days=30&urlversion=2

Test environments:

• https://en.wikipedia.beta.wmflabs.org MediaWiki 1.39.0-alpha (ed4f900) 12:24, 19 August 2022. IP Info 0.0.0 (669fac4) 06:29, 19 August 2022.
• local docker MediaWiki 1.39.0-alpha (b829957) 08:31, 19 August 2022. IP Info 0.0.0 (1f3b6b1) 06:34, 16 August 2022.