We run into the 5000 entry limit *all the time* and having a way to navigate those results would make us much more effective as a team. This would be a good task to prioritize if there is capacity for that.

In looking at how to implement this, a system similar to Special:Contributions seems best to me. This means that the searching for a specific date range, at least for paging, is likely needed. Furthermore, how to log the checks when paging needs to be considered. This could be either:

1. Each pager check is logged with a period to and from that corresponds such that:
   • On checks without a pager, the period is left as is
   • For checks that are truncated, the period is until the oldest timestamp in the results
     • For getting more results, the period is from the newest timestamp to the oldest in the results
2. Only one log entry is generated, and thus for paging the action of getting further results does not result in a new log entry

3. A log entry is generated each time the user looks at one page of results. The log entry message could be like $3, $1 got edits for <bdi>$2</bdi> (partial results)

Good point. One thought about 3 is that I think, like 1, it probably means a new column in the DB as the only column it could really be stored in is the reason column and that seems to hackish for me. In theory the change could be split in two so that the cu_log changes, which will probably take longer to implement, are kept separate and wouldn't hold this up. I suggest this because saying that there were partial results really isn't that important compared to the benefit.

Ideally I'd like to see the interface a bit like Special:Contributions. The ability to choose the number of results per page, and oldest / newest buttons probably won't be useful here and just lead to more code, but the newer X / older X buttons is something that seems much better. These should, unlike Special:Contributions, be submit buttons for some kind of form so that the generating of more results always goes via a post request.

How to log this is still not as clear:

• The default would be to log every time that the user uses the "newer X" and "older X" buttons as a separate log entry. Doing this would not require a modification to the DB right away, but as noted above by Huji it would be best that if this method is used "(partial results)" or something similar is showed. Adding that would require modification to the DB which may take longer to do. However, showing "(partial results)" IMO is not critical (as I said above). Therefore, modification to the DB to include this "partial results" indicator could be done at a later time bringing the benefit of the paging of the results without the wait that a modification to a WMF DB is likely to take.
• Alternatively, a system like Special:Investigate, that logs once for a check even if moving between the pages in the results. However, safeguards on when a log entry can be skipped would be needed potentially making the system more complicated (as CUs could, without the proper safeguard, say that a different check is the continuation of truncated results from a past check). This probably won't need modification to the DB to achieve though as the log entry won't need to store that partial results were shown.

Change 814006 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] T311375: Show results in paginator instead of truncation or hiding

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

The method for logging that I went with is the second system. This should reduce the number of logged checks and won't require a modification to the DB. I'm using JWT tokens through the TokenQueryManager that Special:Investigate uses and then using this to determine if the client modified the values submitted as hidden parameters in a form or if the check was made over a day ago. If either of these is the case, then a new log entry is created. Otherwise, if the data in the JWT token is the same as submitted in the parameters, then logging it skipped as the check has already been logged.

Following feedback and a realisation that it will be more complicated, I've just switched to using a JWT token. This means that the data inside the JWT can be guaranteed to have been generated by the server and therefore it can be used for paging queries.

The method of logging can change, but as this patch is already super large I don't want to be adding a DB row along with it.

Change 814006 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Show results in paginator instead of truncation

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

Change 816304 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] Disable showing the paging navigation bar until paging for Get IPs works

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

Change 816308 had a related patch set uploaded (by Zabe; author: Zabe):

[mediawiki/extensions/CheckUser@master] Omit navigation bar from 'get edits' when there are no results

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

Change 816304 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Disable showing the paging navigation bar until paging for Get IPs works

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

Change 816308 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Omit navigation bar from 'get edits' when there are no results

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