Page MenuHomePhabricator

[wmf.22 testwiki] RC user selected 'Time period to search' in hours does not update "Days to show in recent changes" option
Closed, ResolvedPublic

Description

Here is a summary of discrepancies in the current production testwiki - I am listing here the following scenario:

  • a user selects 'Results to show' and 'Time period to search' options on RC or Watchlist pages (with new filters) and then checks if those changes are saved in Preferences.
testwiki wmf.22
RC Preferences - "Days to show in recent changes" get updated only for whole days value
RC Preferences - "Number of edits to show in..." won't get updated by user selected values
Watchlist Preferences - "Days to show in recent changes get" will be updated for any user selected value
Watchlist Preferences - "Number of edits to show in..." - will be updated for any user selected value

Steps to reproduce:

  1. On RC page select the "Time period to search" option to be different from what was saved in Preferences-Recent changes.
  2. The Preferences-Recent changes "Days to show in recent changes" option will be updated to the user selected value.
  3. Select one of the hours options on RC page - the Preferences-Recent changes "Days to show in recent changes" option won't be updated.

Note 1: Currently it's not even possible to save the value between 0 and 1 in Preferences-Recent Changes "Days to show ..." option. The warning says: "Value must be greater than or equal to 1" which does not cover all valid values for this option.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 17 2018, 10:55 PM
Etonkovidova renamed this task from [wmf.20] RC user selected 'Time period to search' in hours does not update "Days to show in recent changes" option to [wmf.22 testwiki] RC user selected 'Time period to search' in hours does not update "Days to show in recent changes" option.Sep 18 2018, 11:45 PM
Etonkovidova updated the task description. (Show Details)

RC Preferences - "Days to show in recent changes" get updated only for whole days value

This exists in production (enwiki) and isn't a regression, we should create a task to fix this. (Or just use this task to track it.)

RC Preferences - "Number of edits to show in..." won't get updated by user selected values

This works the same way in enwiki currently, so not a regression from T199049

That said, I noticed that if you set number of edits in the RC UI, then visit Special:RecentChanges (without any query params), the number of edits you selected is preserved. So I'm not sure why the preferences are showing a different value. We could either fix the preferences display, or just not display the "number of days/edits" options in the preferences if the user has not opted out of the new RC filters.

Note 1: Currently it's not even possible to save the value between 0 and 1 in Preferences-Recent Changes "Days to show ..." option. The warning says: "Value must be greater than or equal to 1" which does not cover all valid values for this option.

The patch for T199049 only addressed Watchlist preferences, although we could make the same change for Recent Changes.

It seems to be three issues here:
(1) Discrepancies between setting preferences between RC and Watchlist - there were not intended to be.

RC Preferences - "Days to show in recent changes" get updated only for whole days value

This exists in production (enwiki) and isn't a regression, we should create a task to fix this. (Or just use this task to track it.)

RC Preferences - "Number of edits to show in..." won't get updated by user selected values

This works the same way in enwiki currently, so not a regression from T199049

Yes, it's not a regression. I guess we need to fix the existing discrepancies?

(2)

I noticed that if you set number of edits in the RC UI, then visit Special:RecentChanges (without any query params), the number of edits you selected is preserved. So I'm not sure why the preferences are showing a different value. We could either fix the preferences display, or just not display the "number of days/edits" options in the preferences if the user has not opted out of the new RC filters.

(3) Preferences -RC should be fixed to allow users to enter values between 0 and 1.

Note 1: Currently it's not even possible to save the value between 0 and 1 in Preferences-Recent Changes "Days to show ..." option. The warning says: "Value must be greater than or equal to 1" which does not cover all valid values for this option.

The patch for T199049 only addressed Watchlist preferences, although we could make the same change for Recent Changes.

Change 462013 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/core@master] Set consistent min value options for RC and Watchlist filters

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

kostajh moved this task from Inbox to Current Sprint on the Growth-Team board.Sep 21 2018, 7:23 PM
kostajh edited projects, added Growth-Team (Current Sprint); removed Growth-Team.
kostajh moved this task from Incoming to Code Review on the Growth-Team (Current Sprint) board.

@Etonkovidova as far as I can tell, there's not a straightforward way to make RC/Watchlist days/limit hidden preferences if the new RC/Watchlist UI is enabled, so for now I've submitted a patch to just make the settings consistent between RC and Watchlist.

@Catrope @SBisson conditionally showing the preferences seems do-able but it would require modifying Special:Preferences->execute() to recognize a 'hidden' key on the preference definition and then conditionally rendering the days/limit pref depending on whether the user has opted out of the new filters or not.

@Etonkovidova as far as I can tell, there's not a straightforward way to make RC/Watchlist days/limit hidden preferences if the new RC/Watchlist UI is enabled, so for now I've submitted a patch to just make the settings consistent between RC and Watchlist.

@Catrope @SBisson conditionally showing the preferences seems do-able but it would require modifying Special:Preferences->execute() to recognize a 'hidden' key on the preference definition and then conditionally rendering the days/limit pref depending on whether the user has opted out of the new filters or not.

I've +2 the patch above. I think it is better than nothing.

DefaultPreferencesFactory.php:1039 is an example of conditionally-defined preference based on the user.

Change 462013 merged by jenkins-bot:
[mediawiki/core@master] Set consistent min value options for RC and Watchlist filters

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

DefaultPreferencesFactory.php:1039 is an example of conditionally-defined preference based on the user.

I tried something similar. The problem is that if you conditionally add the preference and then the user tries to update their preferences with RC Filters UI, it doesn't get updated because it's no longer recognized as a preference.

DefaultPreferencesFactory.php:1039 is an example of conditionally-defined preference based on the user.

I tried something similar. The problem is that if you conditionally add the preference and then the user tries to update their preferences with RC Filters UI, it doesn't get updated because it's no longer recognized as a preference.

Right, it has to be created with 'type' => 'api' for it to not show on Special:Preferences but still be usable. See DefaultPreferencesFactory.php:1009

I should have put that it my last comment — the issue I ran into with using ‘api’ instead of float/int was that validation no longer occurred when setting the pref via the options API. I’ll see if I can figure something out.

(3) Preferences -RC should be fixed to allow users to enter values between 0 and 1.

There is no reason why watchlist preferences between 0 and 1 should not be allowed, any value greater than 0 would avoid the problems identified in T199049

Etonkovidova closed this task as Resolved.Sep 25 2018, 8:40 PM
Etonkovidova claimed this task.

Checked in wmf.23 - all works as expected.

Reviewing the following case

RC Preferences - "Number of edits to show in..." won't get updated by user selected values

I think that the above behavior is expected since changing the setting will be applied to logs and history and it's better to have a user to change it explicitly in Preferences-Recent changes.