Page MenuHomePhabricator

Make limit sticky adhere to preference limit value
Closed, ResolvedPublic

Description

Right now, the preference for "limit" (number of results) is misleading -- it pretends to only affect RecentChanges but, in fact, it affects the number of results in multiple places that are not outright specified.

For that reason, the "sticky" preference in RCFilters uses a separate hidden preference that takes its initial value from the preference page, but then changes its own value continuously on its own.

The result of that, however, is this:

  • if the user has, in their Preferences page, the limit set to 10 (that is the limit everywhere, including RecentChanges RCFilters)
  • Then the user goes to RecentChanges with RCFilters and sets the limit to 42 (Now the limit everywhere is still 10, but RCFilters' limit is 42)
  • Then the user goes to Preferences page, and changes the limit to 95. (Now the limit everywhere is 95, but RCFilters' limit is still 42)

This can be confusing. We need to solve this. There are several options:

  1. Don't make RCFilters' limit a separate preference. This means that changing the number of results on RCFilters will also change the original preference.
    • Cons: Every time a user changes the number of results for RecentChanges, they actually change it everywhere else too.
    • Pros:
      • It's straight forward and will always reflect what the user sees in the preferences page.
      • It's the way things work right now, even though that's confusing
  1. Make the RCFilters' preference be 'null' if it is equal to the preference in the Preferences page. This means that if that's the case, the RCFilters' preference will, at least, be updated if the user changes the preference in Preference page, unless the user actively and purposefully changed the limit to something else.
    • Cons: It's potentially confusing with the current preference text (but we are going to change that...)
    • Pros: At least the user can have consistent updating of the values when they replace the results.

Whatever we decide, we also need to make sure that the UI displays the values that we consider valid; that is, the base array of options + the custom value from the URL, if it exists + the value from the user default. If the default is singular (the same as the Preference page) then it's one value, but if it's split, we should display both values, so the user can return to equalizing the value between the two defaults.

It sounds like #1 may be the most straight forward, but, seriously, we need to update the text of that Preference on the preferences page, because right now it's under the "RecentChanges" tab, making it sound like it's only affecting RecentChanges when it totally isn't.

Details

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 31 2017, 10:58 PM

Change 368949 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] [propose] RCFilters: Use the base default for 'rclimit'

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

In my opinion, #1 is the least confusing (though I am still very much meh about the fact the preference pretends to only apply to RC while it actually applies to everything) and also the quickest to implement.
I added a proposed solution above.

@jmatazzoni @Etonkovidova Thoughts on #1 vs #2?

I personally favor #1, but I suppose Joe's plans to refactor these preferences also enter the equation.

@Catrope @jmatazzoni Yes, I am for #1 because

  • nobody complained about "coupling" RC preference with history/log
  • a user can see custom "Days to show" and "Number of changes" in UI everywhere as an added option to pre-set options on a page.

Btw, I do not see anything confusing in the following behavior:

if the user has, in their Preferences page, the limit set to 10 (that is the limit everywhere, including RecentChanges RCFilters)
Then the user goes to RecentChanges with RCFilters and sets the limit to 42 (Now the limit everywhere is still 10, but RCFilters' >limit is 42)
Then the user goes to Preferences page, and changes the limit to 95. (Now the limit everywhere is 95, but RCFilters' limit is still >42)

The described behavior preserves RC page settings specifically selected by a user on the page (kind of current working settings, overriding for while Preferences -RC settings) . Such behavior alleviates the fact that Preferences-RC options apply to history/logs and provide more flexible (as a "hidden preference") option to deal with RC only.
(There is a bug when those Preference-RC settings will disappear: T162303: RC page - User preferences for "Days to show in recent changes" and Number of edits to show by default" disappear after some selections are made on the page (I re-opened it)).

Change 369538 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Unsticky the 'limit' preference temporarily

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

As per @jmatazzoni - making the 'limit' parameter non sticky for now.

Change 368949 abandoned by Catrope:
[propose] RCFilters: Use the base default for 'rclimit'

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

Change 369538 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Unsticky the 'limit' preference temporarily

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

Change 369570 had a related patch set uploaded (by Catrope; owner: Mooeypoo):
[mediawiki/core@wmf/1.30.0-wmf.12] RCFilters: Unsticky the 'limit' preference temporarily

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

Change 369570 merged by jenkins-bot:
[mediawiki/core@wmf/1.30.0-wmf.12] RCFilters: Unsticky the 'limit' preference temporarily

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

Mentioned in SAL (#wikimedia-operations) [2017-08-01T23:26:37Z] <reedy@tin> Synchronized php-1.30.0-wmf.12/resources/src/mediawiki.rcfilters/mw.rcfilters.Controller.js: T172156 T171514 (duration: 00m 46s)

A user changes 'Show last changes' and 'Days' options directly on RC page and those settings will be preserved when

  • filters (incl Namespace and Tag filters) added/removed
  • a user navigates away from the page and returns back via browser 'Back' button
  • the RC page is refreshed
  • with the 'Live updates' enabled
  • 'View newest changes' when clicked
  • when Saved filters are loaded

'User preferences - RC settings' will take priority over 'Show last changes' and 'Days' options selected on the RC page in the following cases:

  • when all filters are removed via the trash icon, so 'No active filters. All contributions are shown' is displayed. If the filters are removed one by one by clicking on the 'x' the RC page settings will remain intact, which is an inconsistent behavior.
  • when the link 'Recent changes' on the right side navigation is clicked
  • when 'Restore default filters' is clicked

QA Recommendation: Product should weigh in

jmatazzoni added a comment.EditedAug 7 2017, 6:31 PM

In T172156#3502844, @Etonkovidova wrote:
... QA Recommendation: Product should weigh in

That all seems quite reasonable for the interim, until we do the preference consolitiation. My question for @Mooeypoo is this:

  • When we consolidate preferences, we will eliminate the days and # of changes preferences for RC page.
  • When we do that, what parts of this do we need to change? E.g., I guess we would get rid of the bit where clicking "restore defaults" restores the explicit pref, since there isn't one anymore. What else?

@Mooeypoo, can I ask you to please write a ticket for after the change? I.e., can you please spell out how this should work and what exactly needs to change in a world without RC page preferences, so that we have sticky feature? Actually, this needs to work on Watchlist too, once that has the new UX. The task will have parent tasks T172352, T172349, T172474, T172352 and (tracking task) T172350.

jmatazzoni closed this task as Resolved.Aug 7 2017, 6:33 PM

@jmatazzoni

'User preferences - RC settings' for 'Show last changes' and 'Days' presently play a very little role on RC page, so it seems that the behavior of Show last changes' and 'Days' options that a user sets directly on RC page is more valuable for users.

If we keep the present behavior, then two options should be added

  • a user should be able to customize the number of 'Show last changes' and 'Days' settings directly on the RC page
  • add something like 'Set default' (as it's done for 'Saved filter') for the above settings
  • an option to reset 'Show last changes' and 'Days' to saved defaults