Page MenuHomePhabricator

CU 2.0: Filtering from the data table in Compare tab
Closed, ResolvedPublic3 Estimated Story PointsMar 25 2020

Description

Goal

In the table or lists of results on the CU special page, the user should be able to filter out data using the delete icon that shows up when they hover over a cell.

Mock

https://prtksxna.github.io/wmf-cu-prototype/compare.html (hover over Chrome 65 in the first row)

Unhighlighted row
Screenshot 2019-12-12 at 12.59.33 PM.png (218×1 px, 50 KB)
Hovering over row
Screenshot 2019-12-12 at 1.01.22 PM.png (222×1 px, 55 KB)
Hovering over remove icon (highlights the rows that'll get removed in red)
Screenshot 2019-12-12 at 12.59.44 PM.png (730×1 px, 180 KB)

Acceptance criteria:

  • Requisite filters:
    • Filter out users
  • After the user clicks the cross button, the username is added to the filters widget

image.png (227×775 px, 15 KB)

  • Filters persist across pagination
  • When a new filter is added by clicking the icon, pagination returns to the first page of results.
  • Clicking is a submission of the filter and will refresh the page.
Note

Event Timeline

Which icon is better — trash, cross, funnel?

AFAIK a funnel is generally understood as "filter".

Should we scroll to the Filters form and show where it got added?

With the direction we are headed for the filters to work the page will need to be reloaded. We could add some message saying that the filters changed but I'm not sure that's a good alternative

Which icon is better — trash, cross, funnel?

AFAIK a funnel is generally understood as "filter".

I agree. The problem with the funnel is that it is not clear whether it filters out records with the specific data or filters out all other records. The behavior is the former but I recall myself, Claudia and David being confused over that behavior when we discussed it. So maybe for now let's go with the cross and re-evaluate later?

Actually you are right. A cross makes more sense here since we are excluding from the search in this case

Niharika triaged this task as Medium priority.Dec 17 2019, 10:11 PM
Niharika added a project: Anti-Harassment.

Open questions

  • Which icon is better — trash, cross, funnel?

Let's go with the cross.

*Should we ask for a confirmation before adding the filter and removing the rows?

Hmm, it can take a bit of time to recompute the result-set. We could add a confirmation step...

*Should we scroll to the Filters form and show where it got added?

If the results are all recomputed and re-paginated then it doesn't make much sense to keep them where they were. We should probably bring them back to the first page (irrespective of which paginated page they were on). I don't know if it makes sense to bring the focus on the filter though.

@Prtksxna

Let's go with the cross.

Cool, I'll keep the current mocks as is.

Hmm, it can take a bit of time to recompute the result-set. We could add a confirmation step...

With the direction we are headed for the filters to work the page will need to be reloaded.

If the page is going to reload completely I'm not sure if a confirmation message makes sense. Does the page reload also mean that I can hit the back button and go back to the previous state?

*Should we scroll to the Filters form and show where it got added?

If the results are all recomputed and re-paginated then it doesn't make much sense to keep them where they were. We should probably bring them back to the first page (irrespective of which paginated page they were on). I don't know if it makes sense to bring the focus on the filter though.

You're right, if the page is being reloaded we can just start from the top (first page) and have the filters form be open or closed based on their previous state (however the user left them).

Hmm, it can take a bit of time to recompute the result-set. We could add a confirmation step...

With the direction we are headed for the filters to work the page will need to be reloaded.

If the page is going to reload completely I'm not sure if a confirmation message makes sense. Does the page reload also mean that I can hit the back button and go back to the previous state?

I don't believe so.

Does the page reload also mean that I can hit the back button and go back to the previous state?

I think that would be ideal, assuming all your changing is the filtering and not the investigation itself.

Niharika renamed this task from CU 2.0: Filtering from data in Preliminary check, Compare and Timeline tabs to CU 2.0: Filtering from the data table in Compare tab.Jan 9 2020, 6:24 PM
Niharika updated the task description. (Show Details)
MBinder_WMF changed the subtype of this task from "Task" to "Deadline".Mar 13 2020, 5:39 PM
ARamirez_WMF changed Due Date from Mar 19 2020, 4:00 AM to Mar 25 2020, 4:00 AM.Mar 18 2020, 5:10 PM

I'm going to move this back until I actually start work on it. Feel free to pick it up if you're looking for something to do. :)

Change 583765 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] WIP Add filter buttons in the Special:Investigate Compare tab

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

@Niharika @Prtksxna Since a target could be a username or an IP, should we have filter buttons on all the cells in the user name and IP columns? This means that the user name cells would have "add IPs" and "filter", while the IP cells would have "add users", "filter" and "pin".

@Niharika @Prtksxna Since a target could be a username or an IP, should we have filter buttons on all the cells in the user name and IP columns? This means that the user name cells would have "add IPs" and "filter", while the IP cells would have "add users", "filter" and "pin".

That sounds correct.

While reading this I remembered that we wont be grouping all the usernames together (as we do in the prototype). Does this mean that there would be cases that rows of the same users aren't adjacent to each other? What I am trying to figure out is if we need highlighting and pinning for user names too.

While reading this I remembered that we wont be grouping all the usernames together (as we do in the prototype). Does this mean that there would be cases that rows of the same users aren't adjacent to each other? What I am trying to figure out is if we need highlighting and pinning for user names too.

This shouldn't be a problem - the same users will always be next to each other, since the rows will be sorted by user > IP > UA, and can't be re-sorted.

@Niharika Could we separate the user agent filter into a separate task? Two reasons I'm asking:

  • We have a back-end target filter already (so this task is for adding a front-end interaction), but we don't have a user agent filter yet; it would be cleaner to do this separately.
  • It might even be wise to check how filtering the user agent affects the performance of the query before committing to it.

@Niharika @Prtksxna Could we address this acceptance criterion later, along with T246172?

  • After the results are reloaded, preserve state of filter box - open or closed as before.

The issue of communicating UI state across page loads is being discussed on that task, and this will need a similar solution to whatever we decide there.

@Niharika @Prtksxna Could we address this acceptance criterion later, along with T246172?

  • After the results are reloaded, preserve state of filter box - open or closed as before.

The issue of communicating UI state across page loads is being discussed on that task, and this will need a similar solution to whatever we decide there.

Sounds fine to me.

@Niharika Could we separate the user agent filter into a separate task? Two reasons I'm asking:

  • We have a back-end target filter already (so this task is for adding a front-end interaction), but we don't have a user agent filter yet; it would be cleaner to do this separately.
  • It might even be wise to check how filtering the user agent affects the performance of the query before committing to it.

Yep, sounds good. I'll create a new task for that.

Change 583765 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Add filter buttons in the Special:Investigate Compare tab

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

@Niharika Could we separate the user agent filter into a separate task? Two reasons I'm asking:

  • We have a back-end target filter already (so this task is for adding a front-end interaction), but we don't have a user agent filter yet; it would be cleaner to do this separately.
  • It might even be wise to check how filtering the user agent affects the performance of the query before committing to it.

Yep, sounds good. I'll create a new task for that.

@Tchanders I split that out into T249374: CU 2.0: Filter out exact UAs in the Compare tab. Kept the task description mostly same.

dom_walden subscribed.
  • After the user clicks the cross button, the username is added to the filters widget

Yep.

  • Filters persist across pagination

Yep. Filters are stored in the token, so are preserved for the session.

  • When a new filter is added by clicking the icon, pagination returns to the first page of results.

Yep.

  • Clicking is a submission of the filter and will refresh the page.

After clicking a filter icon the POST request and the SQL submitted to the database is equivalent to using the filter form to filter out the same user/IP.

  • After the results are reloaded, preserve state of filter box - open or closed as before.

The filter box is always closed after the page reloads.

  • The button will only appear on targets that can be filtered out. Some IPs/usernames will not be filterable until T247281: The target filter on Special:Investigate should be more fuzzy [medium] is complete.

As far as I can see, the icon appears on all usernames and IPs (apart from username: "Unregistered").

Screenshots:
Username filter icon:

username_filter_icon.png (164×1 px, 20 KB)

IP filter icon:
ip_filter_icon.png (163×1 px, 18 KB)