Page MenuHomePhabricator

RCFilters UI: Implement 'conflicting' property
Closed, ResolvedPublic

Description

Filters should have a property noting which other filters they may conflict with, so we can represent this state in the UI properly if both those filters are chosen.

This is mostly affecting the tooltip messages above the filter capsule items, but may also affect the visual indication of whether a filter capsule item is "active" or greyed-out.

More specifically, the rule is that Group A conflicts with option B if and only if all selected items of group A are in conflict with option B

The backend will include an array of the conflicting filters in each filter when those are defined, see T152754: Configure filters in a single extensible place for the spec of those definition.

Related Objects

StatusSubtypeAssignedTask
Resolved DannyH
Resolved DannyH
Resolved jmatazzoni
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
Resolved jmatazzoni
ResolvedNone
InvalidNone
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
ResolvedSBisson

Event Timeline

Change 335951 had a related patch set uploaded (by Mooeypoo):
[wip^n] Define interaction states for filters

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

Change 336359 had a related patch set uploaded (by Mooeypoo):
[wip] RCFilters UI: Filter interaction: conflicts

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

Change 335951 merged by jenkins-bot:
RCFilters UI: Define interaction states for filters

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

Change 336359 merged by jenkins-bot:
RCFilters UI: Filter interaction: conflicts

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

For testing

Unregisterall filters in Experience levelConflicting - YES
UnregisteredBotConflicting - NO
UnregisteredYour own editsnew filters are not provided for non-logged in users; NOT conflicting state
Minor editsPage creationNOT conflicting
Minor editsLogged actionsNOT conflicting
Minor editsCategory changesNOT conflicting

Our intention in defining the Conflict states was to give users help ONLY with those combinations that yield no results and which are a) structural, meaning they happen every time, by definition; and b) are hidden, meaning that the users will likely not be able to figure out the conflict. The only states I'm aware of that meet those conditions are defined in the Active Filter Display Area ticket under Conflict States.

Which is to say, I don't think we need to create special messages for all the settings that may yield no results. There are plenty of illogical settings (Edits by me + Newcomers, Logged actions + Minor... etc. ), and we can leave these to users' intelligence.

So, e.g., if I select Changes by me AND Bots, then with a little thought I should be able to figure out for myself why I got no results (I'm not a bot). In such cases, the standard Results-area message, "No results for the selected criteria" (or whatever it says), should be sufficient. (And, also, it is just possible that a user has logged in using the bot he invented's account--which is to say, this combination may not be "structural" in the intended sense.)

Change 340909 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core] RCFilters UI: Adopt conflict colors

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

Change 340909 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Adopt conflict colors

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

Change 343137 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core] RCfilters UI: Change mute display for included filters

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

Change 343137 merged by jenkins-bot:
[mediawiki/core] RCfilters UI: Change mute display for included filters

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

Checked the conflicting states according to T156427: Implement the Conflict display states and messages (except for Wikidata - it's not present yet)
Unregistered with all User experience filters
Logged actions with Contribution quality predictions
Logged actions with User intent predictions

  • The UI displays conflict states marked as red
  • The conflict state(s) is indicated among selected filters as soon as a user makes such a selection, e.g.

Screen Shot 2017-03-17 at 12.33.13 PM.png (166×1 px, 42 KB)

Screen Shot 2017-03-17 at 1.05.45 PM.png (319×724 px, 52 KB)

There are no

  • tooltips
  • the message is still generic: "No changes during the given period matching these criteria."

@jmatazzoni Regarding "illogical states"

There are plenty of illogical settings (Edits by me + Newcomers, Logged actions + Minor... etc. ), and we can leave these to users' intelligence.

I think we should revise our approach to them (maybe, as part of 'Beyond phase I' ) - because there is logic in such states. As far as I could find, 'Page creation' is never marked as 'Minor edit', and if I am not qualified as an experienced user, so, when I select 'Your own edits' and 'Experienced users, I should be informed that 'No results found because the search criteria are in conflict'.

Both of those should be implemented now. @Etonkovidova can you retest?

Re-tested in betalabs (along with testing T160803: Implement corrected Conflict State tooltips and Results Area messages )
-Conflict states are fully covered (except for Wikidat and for arguable filter states as e.g. Page Edits+Minor Edits; Logged actions+Minor edits)
-Correct tooltips are in place
-the area result message correctly refers to the conflict that occurred

QA recommendation: Resolve.