In T248514#6302778, @MusikAnimal wrote:

Yup. I did forget to reference this task in the patch. I've got another patchset coming shortly and will fix that.

@MusikAnimal isn't this included as part of the work on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/602486 ?

@Marostegui Thank you so much for your reply. I'll try to answer your questions below

In T253823#6224695, @dom_walden wrote:

Oh, another thing I noticed: while on one of the tabs, if I change the interface language (e.g. via uselang URL param or Special:Preferences) and refresh I am taken to a blank page (no data, just the 3 tabs). This appears to be because the URL is still in whatever my language was before I changed it, but now it expects it to be in the language I just changed to.

I don't know if this will be a problem in reality. Do CheckUser need to change their interface languages mid-investigation for any reason?

Or we could just do [0|1|2] for the tabs like Gmail does for the different accounts. It is very unlikely that someone will "type" the URL to the subpage 'cause the token is needed.

Short answer is Yes, this is what GuidedTour is for.

In T249239#6200423, @Prtksxna wrote:

Some changes coming up on this task. We've changed the interface quite a bit here, and I am not sure if a nested menu would make things too complicated.

Add dropdown for
Include /16 range and Include /24 range for IPv4 IPs
Include /32 range and Include /64 range for IPv6 IPs

Based on the usability tests we now want a more fine-grained control here. @Niharika, what is the range we want to provide here? 1 to 24 for IPv4, and 1 to 64 for IPv6?

Updating status to Open now that https://gerrit.wikimedia.org/r/594292 is merged

Technically we could allow for a “re-pin” if no highlights are present in the current page although it might confuse the user thinking that it does not persist across pages.

@Prtksxna

In T252033#6137325, @Tchanders wrote:

This behaviour makes sense too. Are you aware of any precedent to not show the contribs link at all when there are no contributions?

I'm not aware of anywhere that does this. The links are handled by Linker::userToolLinks, which we're calling with $redContribsWhenNoEdits = true.

If we did want to remove the contribs link, we should be able to do so using css, using the classes mw-usertoollinks-contribs and new. I'm not sure whether we should do that if it's not done anywhere else... Absence of a link might be interpreted as a bug by users who are used to seeing a red link?

@Tchanders I'm a bit confused. Are you saying that the implementation before the patch on this task works better? if that's the case I do not disagree. This patch only exists to match current functionality of Special:CheckUser

Extra info: Seems to have been added back in 2009 git show 4124558d7b4 maintenance/tables.sql.

Disregard my last comment. I was still organizing my thoughts and pressed submit by mistake.

In T250446#6094740, @thcipriani wrote:

Adding in Anti-Harassment folks to see if this is at all related to recent refactoring work on CheckUser.

@DannyS712 @Aklapper, thank you for this!

In T249059#6032472, @Marostegui wrote:

The test host would be the closest (same data and same HW specs as we have in production), however it will have just a one time snapshot, meaning that the data won't get updated, so you'd be testing always with the same data.

In T249059#6032405, @Marostegui wrote:

What we can also do is use the "test" hosts (https://wikitech.wikimedia.org/wiki/MariaDB#Testing_servers) and load one big wiki, maybe enwiki and give some access there for some users so they can test queries against enwiki?
Would that work for query testing?

So to summarize what has been discussed. This task is only to generate the query that will be consumed by the pager. It does not involved any data massaging or any extra handled on the pager. That work will be done as part of T247640: CU 2.0: Add the timeline tab with a list of generic structured results [medium]
With that said, is it fair to say that the last 3 bullet points on the Acceptance Criteria can be removed since they'll be handled in T247640?

In T247639#5988424, @Tchanders wrote:

Is this what we want here? No pagination and a sensible limit?

When we discussed T247640 in estimation we planned to make a pager, though it looks like this hasn't been documented in the task yet.

Looking at the current "edits" option on CheckUser, there is no pagination and a limit of 5000 rows.

@Niharika can we have a separate ticket for displaying the "Logs" button at the top right? Or maybe group it with the ticket for "new investigation"? I can't find that task if one already exists.

One thing to keep in mind is that there is nothing preventing yourself from adding your own username to the email or echo blacklists via Special:Preferences. That was one of the reasons why we didn't enforce this rule IIRC. I do not disagree with hiding the link when it applies tho.

Clicking the "Show all N IPs" button adds another IP target for each relevant IP, in addition to the currently-entered targets.

There is also the issue of adding the new target to the investigation. Considering that server requests are logged, we might have to either pre-generate a token with the new target (possibly expensive) or potentially do it via a POST request. The latter seems more reasonable and @dbarratt mentioned it is what he'll be doing with the filters.

Thanks @Dzahn . Here is mine

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMzAnzpZdT/jiyru+B+bUxA/r04r6kPBEl/aBQmuBlmU dmaza@wikimedia.org

Couple questions:

• Define: full coverage
• How useful is it really to test a special page? What exactly is it expected to be covered here?
• Same as above for pagers. Specially when most of the methods are calling a method in the service.

In T237299#5914044, @Tchanders wrote:

Why can't we do it using local storage?

This is a good question. It did cross my mind, but there are a few issues:

• since local storage is shared across tabs, the highlighting would be the same across all open investigations (we could perhaps make a unique ID for each investigation, but we're wandering into the territory of making maintenance more difficult)
• we'd need to be careful not to pollute the store (e.g. making sure we delete everything if the user closed the tab without removing the highlight)
• window.sessionStorage would be an alternative, but this wouldn't be able to be deliberately persisted across tabs (e.g. if there were multiple pages open from the same investigation)

In T237299#5911901, @Tchanders wrote:

@Tchanders To confirm - sticky highlights persist across paginated tabs right?

@Niharika Not in the current patch. We could do this by adding some extra information to be passed via the token: i.e. the data that should be highlighted when the next page loads.

Why can't we do it using local storage? It would mean that you will have to add the pin button to the first match in the new page so to allow the user to "unpin" but other than that I don't see a problem. Am I missing something?