[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

[Epic] CheckUser 2.0: Compare
Closed, ResolvedPublic

Description

Goal

This ticket is for adding a Compare tab to the redesigned CheckUser interface. This step is where the actual CheckUser data will be exposed.

Mock

https://prtksxna.github.io/wmf-cu-prototype/index.html

image.png (1×2 px, 272 KB)

Filters

  • Hide the following users
    • Auto-completes with usernames being displayed in the table below
    • On adding a username to the widget, the result rows for that username go away
  • Hide the following IPs
    • Auto-completes with IP address being displayed in the table below
    • On adding an IP to the widget, the result rows for that IP address go away
  • What happens when the user gets rid of all the rows in the table with the filters -

Screenshot 2019-11-18 at 3.36.44 PM.png (182×1 px, 34 KB)

  • We'd need to have a loading animation for when the results are being filtered/reloaded -

Screenshot 2019-11-18 at 3.39.10 PM.png (142×2 px, 12 KB)

https://codepen.io/Volker_E/pen/yqNXMe

Data tables

The information we want to display
Common stuff
  1. Activity
    • Datetime of their first known edit from that IP - Datetime of their last known edit from that IP
  2. User-agent
    • Shows the complete UA string
    • Use the total width of the Browser and OS columns in the above mock-up to show the UA string instead
    • Note - The mock includes splitting the UA and showing device info (phone vs desktop). We'll do that in future iterations. Let's start with the very basics.
Uncommon stuff

If they looked up a username

  1. Username
    • The username being looked up.
  2. IP
    • This is the IP address the edit/action was made from.
    • The IP address doesn't link anywhere (unlike the mock currently)
    • A count for number of edits made from that IP address in that time period from that user in bold
    • Following the mock, there is a count for how many edits were made from that IP address by other users ($x from $y other users)
    • User-customizable list of links under the IP address - this is currently customized on the wiki by https://en.wikipedia.org/wiki/MediaWiki:Checkuser-toollinks. We should use the same config variable for now.

image.png (194×540 px, 22 KB)

If they looked up an IP

  1. IP

image.png (194×540 px, 22 KB)

  1. Username
    • Users editing from the given IP address(es). The field contains a Unregistered if to show edits/actions from unregistered users. @Prtksxna thoughts?
    • A count for number of edits made from that username from that IP address in that time period in bold
    • A count for how many other edits were made by that user from other IPs (//$x from $y other IPs)
Mock: One table - visual distinction between which ones were entered by user
UsernameActivityIPUser-agent
ApplesAugust 12, 11:00 - September 13, 10:001.2.3.4 - 17 edits (10 from 3 other users)Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
ApplesAugust 16, 13:00 - September 1, 8:001.5.6.4 - 123 edits (1560 from 35 other users)Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
BananasAugust 12, 11:00 - September 13, 10:001.2.3.4 - 17 edits (10 from 3 other users)Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
BananasAugust 16, 13:00 - September 1, 8:001.5.6.4 - 123 edits (1560 from 35 other users)Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
GrapesAugust 12, 11:00 - September 13, 10:00 1.5.6.7 - 17 editsMozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
UnregisteredAugust 16, 13:00 - September 1, 8:00 1.5.6.7 - 123 editsMozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
PineapplesAugust 12, 11:00 - September 13, 10:00 1.9.8.4 - 17 editsMozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
UnregisteredAugust 16, 13:00 - September 1, 8:00 1.9.8.4 - 123 editsMozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15

Note: This table previously had information like (10 edits from 3 other IPs) next to the usernames found by putting in an IP address but I've taken those out as it doesn't seem useful and is not present in the current CU interface.

Related Objects

StatusSubtypeAssignedTask
OpenNone
ResolvedNiharika
ResolvedNiharika
OpenNone
ResolvedReedy
OpenNone
OpenFeatureNone
Resolvedsbassett
ResolvedTchanders
OpenNone
Resolveddmaza
Resolveddmaza
ResolvedTchanders
ResolvedTchanders
Resolveddmaza
Resolveddbarratt
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
ResolvedTchanders
Resolveddmaza
Resolveddbarratt

Event Timeline

Mock

https://prtksxna.github.io/wmf-cu-prototype/compare.html (source)

cu-proto-compare.png (653×1 px, 53 KB)

@Niharika ^^^^ for Description.

@Prtksxna: I'd add a minor feature - a "Proxy/VPN check" link - after "Tor check" (pull request): <a href="https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/<?=$IP ?>">Proxy/VPN check</a>

For geolocation (no link in prototype) I prefer to use "https://www.iplocation.net/?query=<?=$IP ?>"
which presents data from 3 sources (that often differ). These include https://whatismyipaddress.com/ip/1.1.1.1 and https://db-ip.com/1.1.1.1 currently used on IP contributions pages
Note: one more useful alternative (50/day free requests only): https://www.ip2location.com/demo/1.1.1.1

A more substantive task.
Add 3 columns: Subnet (name and ip range of the subnetwork), Geolocation (closest city, generally), Proxy/VPN (reported/detected proxies)
This would greatly increase the efficiency of recognizing IPs from around the world (VPN users), dynamic ips on the same subnet, open proxies/free VPNs, etc.

Edits are grouped by IP+UA on the mockup, summing edit count. Edits from the same subnet should be grouped together as well. This will collapse potentially dozens of IPs for dynamic IP users.

The subnet (Whois), geolocation, proxy info is aggregated from on-site databases or online services.
The task to develop the backend is: T174553: Create a mechanism that allows fetching geolocation and subnet data for IP addresses

From the description:

@Prtksxna What happens when the user gets rid of all the rows in the table with the filters?

If this, happens we should leave the filters box open and show a notice. The notice should let them know what has happened with an option to remove all filters. You can see an example here - https://prtksxna.github.io/wmf-cu-prototype/empty.html

Screenshot 2019-11-18 at 3.36.44 PM.png (182×1 px, 34 KB)

@Prtksxna We'd need to have a loading animation for when the results are being filtered/reloaded.

For the loading animation we'll use the same one as RecentChanges (and other places on the site). You can find the code in Volker's codepen - https://codepen.io/Volker_E/pen/yqNXMe

Screenshot 2019-11-18 at 3.39.10 PM.png (142×2 px, 12 KB)

I have added an example in https://prtksxna.github.io/wmf-cu-prototype/index.html. Clicking submit now shows the loading indicator for two seconds before loading the table.

Niharika triaged this task as Medium priority.Nov 19 2019, 6:39 PM
Niharika updated the task description. (Show Details)

Notes from the estimation meeting

  • We want to start with server side pagination and iterate upon it later, depending on whether we need client side pagination or not.
  • Highlights, sort and filters would stay sticky across the paginated tabs (is that the right word?)
  • We decided to go with Option 2 in the task description as it makes sense to filter/highlight all data together. We will need a good way to visually distinguish users and IPs the user explicitly queried for.

Tickets we want to split this into:

  1. Getting the data, sorting and pagination - 8
    • This includes getting the requested data from the server with the sort options selected by the user. Sorting can be done by username, IP and user-agent. No sorting by activity.
  2. Display the data - 3
    • This involves displaying the data in the table. Assuming no filters or highlights exist at this point.
    • Records sorted by the options pre-selected by the user. If no options are previously selected, they are grouped by the usernames and IPs requested by user. If a username and an IP were both looked up, we club the record with the username.
  3. Building the filters and filtering
    • This task is to build the filtering UI and doing the actual filtering in the UI. Works across paginated tabs.
  4. Build the sticky highlights
    • This task is to build the sticky highlighting UI. Sticky across paginated tabs.
  5. Adding the new data records
    • This task is to add the new records to the table when a user clicks the 3 other IPs or 4 other users links (or however the design wants to make that work).

@Rxy The AHT team has taken on rewriting and redesigning CheckUser as part of the general strategy around this area. This means that we are *heavily* editing the code, and the plan is to replace the current CheckUser special page with the new one that we're building.