Page MenuHomePhabricator

Make the Number of Edits and Number of Days settings sticky (and adjust the Preference pg. behavior appropriately)
Closed, ResolvedPublic

Description

We have always wanted to make the # of results and # of days settings on Recent Changes sticky, but were unsure how these should interact with the Recent Changes preferences. After some debate we decided on the following:

On Watchlist

  • When the New Filters are enabled on Watchlist, the Days and # of edits settings are hidden.
  • Meanwhile, the tools on Watchlist itself are sticky. In other words, the Preference no longer has a role and the local controls in effect become the preference.
  • If the user opts out of the New Filters, then the Watchlist preferences are reinstated.
  • The New Filters sticky controls should update the hidden WL preferences behind the scenes, so that, should the user opt out of the New Filters, the user's current local settings will be established automatically as Preferences.

On Recent Changes

  • The # of Days control works as on Watchlist: i.e., the Preference is hidden for users with the New Filters, and the local, sticky controls take precedence.
  • Because various pages besides RC page share the RC page # of Edits control, however, we will craft a different solution for this:
    • The Preference page preference will not be hidden for New Filters users. The preference for # of edits will establish the initial state on RC page (as well as various other pages) as now.
    • However, if the user changes the # of Edits setting on RC page itself, this local setting will override the preference for RC page only (i.e., the local setting will not change the explicit preference setting or affect any page except RC page). The local setting will be sticky and will remain in effect until the user changes t.
    • However, if the user goes back at any time and changes the setting on the Preference page, that will now wipe the sticky slate clean on RC page, overriding the sticky setting—until such time as the user may make a new local change.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 29 2017, 3:54 AM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 29 2017, 3:55 AM

I don't understand this ticket. Is there anything I need to do?

This is to solve the sticky preference issue as we discussed (taking into account that the limit setting on Special:RC is sticky, but there is also a Special:Preferences limit setting).

You should review the i18n changes.

jmatazzoni updated the task description. (Show Details)EditedSep 14 2017, 8:06 PM

@Mattflaschen-WMF, do the language changes you describe happen only for beta users?

Sorry, i just realized that we are graduating this out of beta, of course.

So, if i understand this correctly (once Roan explained it to me), what you're doing is a) making it so that the Preference pg DOES set these figures but b) the sticky controls on RC page will override them. Is that right?

If so, then the language you propose, it seems, is wrong, since as noted above, the preference DOES apply to RC page as well.

@Pginer-WMF, can I ask you to please sort this out and come up with a solution that makes sense?

If so, then the language you propose, it seems, is wrong, since as noted above, the preference DOES apply to RC page as well.

The idea is:

  • If they have not touched the sticky controls on Special:RecentChanges, "This includes page histories and logs." is correct because it includes those two things. (It also includes RC, but we never said it didn't.)
  • If they have touched the sticky controls on Special:RecentChanges, "This includes page histories and logs." is correct because it includes those two things (and not RecentChanges).

Granted, this is a bit tricky, but I think mostly in theory, not in practice. The advantage is it respects your existing preference.


However, an alternative proposal (totally separate from above) is:

  1. Do a one-time copy of the existing shared preference to a Special:RecentChanges-specific preference.
  2. Going forward, the limit at Special:Preferences will never affect the Special:RecentChanges page.

However, we'd need to decide what to do if you disable the Structured Filters UI. Options:

  1. It's still sticky (can be done server-side).
  2. It then uses the Special:Preferences value only while it's disabled.
  3. You just can't change the limit.
jmatazzoni added a subscriber: Mooeypoo.EditedOct 16 2017, 11:09 PM

I'm lost on this one. @Mooeypoo can you perhaps summarize:

  • What is the current status quo re. this?
  • What is the problem Matt is wanting to solve?
  • What does Matt think we should change?

@Etonkovidova, perhaps you can explain?

New proposal: let's make these sticky again. For rclimit, use a hidden preference like we did before, but when rclimit is changed, change the hidden preference too (or wipe it out). For rcdays, wllimit and wldays, update these directly and hide them from the preferences page if the new UI is enabled.

jmatazzoni renamed this task from Make the sticky parameters sticky (again) to Make the Number of Edits and Number of Days settings sticky (and adjust the Preference pg. behavior appropriately).Oct 31 2017, 4:45 AM
jmatazzoni updated the task description. (Show Details)

I updated the Description for this task above to reflect what we said in the Triage meeting, and I've moved this to RFP. My notes from that day were as follows, and I think I've captured what we intended:

  • RC #results gets reused, so keep it, and when you change it, we wipe separate hidden sticky
  • RC Days invisible if new filters enabled (not disabled)
  • WL days and number, invisible if new filters enabled (beta enabled)
  • All of those sticky.

@Mattflaschen-WMF and @Catrope and @Trizek-WMF review what I wrote up top and make sure that is what you were thinking.

The edited task description looks good to me. One nitpick:

  • It may be desirable to have the New Filters sticky controls update the hidden WL preferences behind the scenes, so that, should the user opt out of the New Filters, the user's current local settings will be established automatically as Preferences. However, if this i s complicated, it's not necessary; it is perfectly acceptable to simply establish the default settings on opt-out if that is simpler.

If anything this is less complicated, as we'd have to create separate preferences for these otherwise.

! In T174415#3727202, @Catrope wrote:

If anything this is less complicated, as we'd have to create separate preferences for these otherwise.

Thanks Roan. I rewrote the spec as follows:

  • The New Filters sticky controls should update the hidden WL preferences behind the scenes, so that, should the user opt out of the New Filters, the user's current local settings will be established automatically as Preferences.

Change 388264 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Make 'days' and 'limit' sticky

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

Change 388264 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Make 'days' and 'limit' sticky

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

Below are two test scenarios to check opt-in/opt-out settings saving and whether user selected options on Watchlist are successfully preserved in Preferences-Watchlist

(1) Watchlist Preference settings are preserved between opt-in and opt-out

User actionPreferences-Watchlist options Result on Watchlist
1New filters enabled, default settingsDays to show in watchlist: 3; Maximum number of changes to show in watchlist: 250Time period to search: 3; Results to show: 250
2User changes Preferences-Watchlist optionsDays to show in watchlist: 5; Maximum number of changes to show in watchlist: 25Time period to search: 5; Results to show: 25
3User opts out from New filters beta featureDays to show in watchlist: 5; Maximum number of changes to show in watchlist: 25Period of time to display: 5 days
4User changes Preferences-Watchlist optionsDays to show in watchlist: 6; Maximum number of changes to show in watchlist: 26Period of time to display: 6 days
5User opts in to New filters beta featureDays to show in watchlist: 6; Maximum number of changes to show in watchlist: 26Time period to search: 3; Results to show: 250

(2) Watchlist page user settings are saved in Preference only when New filters are enabled - the test case in bold illustrates that user setting on Watchlist without new filters won't be saved in Preferences-Watchlist.

User actionWatchlist page options Result on Preferences-Watchlist options
New filters enabled; user sets options on WatchlistTime period to search: 1 day; Results to show: 50Days to show in watchlist: 1; Maximum number of changes to show in watchlist: 50
User opts out from New filtersPeriod of time to display: 1 dayDays to show in watchlist: 1; Maximum number of changes to show in watchlist: 50
User changes Watchlist settingPeriod of time to display: 7 dayDays to show in watchlist: 1; Maximum number of changes to show in watchlist: 50
User opts in for New filtersTime period to search: 1 day; Results to show: 50Days to show in watchlist: 1; Maximum number of changes to show in watchlist: 50

The RC page settings (Preferences-Recent Changes and user settings on RC page itself) were tested for the test scenarios as for Watchlist.
To summarize - all specs are in place:

  • without the new filters enabled, user selection for "Show last changes" and the # of days to show on RC page won't be preserved in Preferences-RC and with opt-in
  • with the new filters enabled, # of days selected by a user on RC page will be saved as Preferences-RC "

Days to show in recent changes"

  • user selected "Results to show" on RC page will not be preserved as "Number of edits to show in recent changes, page histories, and in logs ..." on Preference-RC page. So, if a user opts-out from the new filters, the settings in Preferences-RC will take the effect. When a user opts in, the previously selected user settings on RC page will be displayed.

QA Recommendation:Resolve

jmatazzoni closed this task as Resolved.Dec 11 2017, 4:15 PM