But I'm wondering if it's a temporary problem to do with the DB migration, or whether it's likely to persist.

@Tchanders is there someone we can ping to ask about this? If it's a temporary problem then we may not need to do anything here?

We could leave this as it is in the screenshot above (T326393#9114423), since the IPs for those log events are technically unavailable. If the patroller wants to know the precise IP used for any of the events not stored in CheckUser, they can't, because we didn't store it. (Though in the particular example of create/upload, they can work it out.) They can see IPs associated with revisions on Special:Contributions, history pages, etc.

This makes sense to me but I would like us to be able to tell the user why this IP is not available in case they mistake this for the IP no longer being in the database (such as if it's past the 90 days mark). Alternately we could share the most recent IP with them but let them know (through a help link or similar) that this may not be what they think it is.
@KColeman-WMF @Whatamidoing-WMF do you have thoughts on this task?

In T345068#9123429, @Niharika wrote:

But I'm wondering if it's a temporary problem to do with the DB migration, or whether it's likely to persist.

@Tchanders is there someone we can ping to ask about this? If it's a temporary problem then we may not need to do anything here?

As I'm leading this DB migration, my understanding is that if cu_changes rows could be looked-up by their log ID the same problem would occur. The migration was designed such that the new table structure would not collect any more or any less data than before the migration.

Addressing this problem, as discussed in T326393, is not easy. I see three options:

1. Tell CheckUser to store data for every row in the logging table.
2. Update code that creates log events to send the log event to Special:RecentChanges
3. Update code that creates log events to add an entry to cu_log_event but for this entry to not be displayed or used anywhere other than the IP reveal feature.

I would prefer number 3, as in the cases I've seen so far the issue is that the log entry is somewhat duplicated (i.e. page creation happens at the same time as the upload). This means no somewhat duplicated entries are shown in either Special:RecentChanges or Special:CheckUser, but the IP reveal feature still has access to the IP. This could be done through a different table if desired.

In T345068#9123429, @Niharika wrote:

We could leave this as it is in the screenshot above (T326393#9114423), since the IPs for those log events are technically unavailable. If the patroller wants to know the precise IP used for any of the events not stored in CheckUser, they can't, because we didn't store it. (Though in the particular example of create/upload, they can work it out.) They can see IPs associated with revisions on Special:Contributions, history pages, etc.

This makes sense to me but I would like us to be able to tell the user why this IP is not available in case they mistake this for the IP no longer being in the database (such as if it's past the 90 days mark). Alternately we could share the most recent IP with them but let them know (through a help link or similar) that this may not be what they think it is.
@KColeman-WMF @Whatamidoing-WMF do you have thoughts on this task?

I would agree with the idea of telling the user if the IP being displayed is the most recent (instead of the one that was associated with the given log).

But I'm wondering if it's a temporary problem to do with the DB migration, or whether it's likely to persist.

Sorry, I didn't mean to paste this sentence into the task description - we already discussed it and it will persist!

I would like us to be able to tell the user why this IP is not available in case they mistake this for the IP no longer being in the database (such as if it's past the 90 days mark). Alternately we could share the most recent IP with them but let them know (through a help link or similar) that this may not be what they think it is.

Yes, I agree we should explain it to the user, to avoid any confusion. Perhaps we can use the PopupButtonWidget (i icon) to provide further information?

@KColeman-WMF I think we're likely to use the (i) icon for the IPInfo popup next to a temp username:

Is there something else we can do, either to let them know that the IP for this action is unavailable, or to display the most recent IP and let them know that's what we've done?

It sounds like there is agreement that we show the user the most recent IP we know of and let them know that that's what we are doing. I like the idea of using the info icon to do this.

@Tchanders @KColeman-WMF is there any outstanding product questions here besides this?

In T345068#9908763, @Niharika wrote:

It sounds like there is agreement that we show the user the most recent IP we know of and let them know that that's what we are doing. I like the idea of using the info icon to do this.

Please don't - it would be inaccurate information (that would need to be ignored as such). If an IP isn't available, don't display one. If someone wants the most recent IP, they can reveal the most recent action.

@Niharika could you take a look at this please, and update the task description with the decision?

In T345068#9910196, @JJMC89 wrote:

In T345068#9908763, @Niharika wrote:

It sounds like there is agreement that we show the user the most recent IP we know of and let them know that that's what we are doing. I like the idea of using the info icon to do this.

Please don't - it would be inaccurate information (that would need to be ignored as such). If an IP isn't available, don't display one. If someone wants the most recent IP, they can reveal the most recent action.

Per the above, it sounds like we should keep the status quo of showing "unavailable". Improving the UX for this via additional information sounds nice, but not a minor pilot wiki blocker.