Value of 0 for "Days to show in watchlist" or "Maximum number of changes to show in watchlist" setting breaks watchlists; should instead be interpreted as maximum or no limit
Closed, ResolvedPublic

Description

Per T176033 and T198961 setting the value of "Days to show in watchlist" in Special:Preferences#mw-prefsection-watchlist breaks watchlists in that no changes are displayed (in my testing even changes less than 1 minute old were not shown). This value is therefore nonsensical. At T176033#4115252, @Krinkle noted that there are over 1000 users with this setting on Commons alone, suggesting that it previously gave a useful result (this change presumably occurring circa early September 2017).

It is most probable that users a setting a value of zero intended this to mean that that there should be no limit to the number of days displayed, and this would seem to me to be the most logical behaviour going forwards. If no limit is not technically possible, then interpreting 0 as equalling the value of the maximum number of days currently defined for that wiki (i.e. not a hardcoded value) would achieve equally useful results in practical terms.

Similarly the same logic should apply to the "Maximum number of changes to show in watchlist" setting, with 0 meaning "no limit" or "maximum", with the watchlist displaying all changes until whichever of the time or number limits is reached first.

If 0 is equal to "no limit" then MediaWiki should not allow both preferences to be set to this value. If 0 is equal to maximum there will be no issues (that I am aware of) with both being 0.

See also: T176857: Watchlist links with "&days=0" give an incorrect display

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 8 2018, 10:54 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I suppose another approach would be to disallow 0 as a value and change all existing instances of this value to be equal to the current maximum. This would be less preferable to the above though.

Quiddity updated the task description. (Show Details)Jul 8 2018, 8:07 PM
JTannerWMF moved this task from Inbox to To Triage on the Growth-Team board.Jul 10 2018, 5:29 PM
MMiller_WMF moved this task from To Triage to Revisit on the Growth-Team board.Jul 10 2018, 5:45 PM

To summarize the findings (and for further checking after the fix):

(1) The fix in T176857: Watchlist links with "&days=0" give an incorrect display was to restore the previous functionality, so

watchlist links with a "days=0" URL parameter to interpret that as meaning 0 days rather than "all available days" as it previously did.

It seems that such interpretation (0 days as all available days) was useful to some user.

(2) Presently (wmf.12), the Preferences-Watchlist options "Days to show in watchlist" and "Maximum number of changes to show in watchlist" can be set to zero and users' experience is documented in the table below.
Note: the testing is done on testwiki where the "Period of time to display" system option default is set to "1 hour" in the seletor.

"Days to show in watchlist""Maximum number of changes to show in watchlist"the displayed messageafter clicking on 'Show'
00"Below are the last 0 changes in the last 0 hours ""Below are the last 0 changes in the last hour"
0not zero"Below are the last 0 changes in the last 0 hours" Actual results will be shown - the user settings will be overridden
not zero0"Below are the last 0 changes in the last [number set] hours""Below are the last 0 changes in the last [number set] hours"

(3) The '0' value is explicitly specified as a valid value:

(4) The related tasks are the following:
T176033: Watchlist param days=30 doesn't override user preference 'watchlistdays' = 0 - added as a subtask
T176857: Watchlist links with "&days=0" give an incorrect display - it may be re-opened
T198961: Watchlist on meta wiki not displaying changes until "show" button is clicked - marked as duplicate to this task

IMO clicking "show" should always display the results of the settings in the form, even if they are unchanged and even if the defaults differ from user preference settings (what the defaults should be is an unrelated issue).

I cannot think of any situation in which actually displaying the last 0 changes and/or changes in the last 0 hours (i.e. showing a watchlist which never has any changes on it) would be a useful feature.

Obviously the message should match what is actually displayed but this is just a trivial aspect of this, the key part is correcting the part of rMWb747307a2002 that broke the previous, useful, behaviour of days=0

I suppose another approach would be to disallow 0 as a value and change all existing instances of this value to be equal to the current maximum. This would be less preferable to the above though.

I'd like to advocate for this, actually. On the watchlist preferences, the user can see what the maximum allowable value is for both the number of days and number of items to show:

A user could then set the day / limit values based on the information provided there, which IMO is more intuitive than informing them that the value of 0 can also be used as a maximum.

My suggestion for this task would be:

  • script to migrate preference data for users who have 0 set for days / limits to the max days and max limit
  • disallow 0 as a value for days / limits in Watchlist and RecentChanges prefs
  • Optionally, add the UI from RecentChanges that provides a clickable link for setting the limit parameter in the URL

We (thanks @SBisson and @Catrope!) ran a few queries to see who this is impacting.

First we looked at users who had watchlistdays = 0

enwiki has 26793 users with watchlistdays set to 0, dewiki has 6251, and the other large wikis I checked are also all over 1000 (1507 on zhwiki, 1404 on jawiki, 2247 on frwiki).

But then @SBisson narrowed the queries down

1-- USERS WITH LIMIT=0, DAYS=0 ACTIVE THIS YEAR
2mysql:research@s3-analytics-slave [enwiki]> select count(user_id) from user inner join user_properties as upl on user_id=upl.up_user and upl.up_property='wllimit' and upl.up_value in (0, '0') inner join user_properties as upd on user_id=upd.up_user and upd.up_property='watchlistdays' and upd.up_value in (0, '0') where user_touched >= 20180101000000;
3+----------------+
4| count(user_id) |
5+----------------+
6| 1764 |
7+----------------+
81 row in set (0.68 sec)
9
10-- USERS WITH LIMIT=0, DAYS=0, WHO HAVE OPTED OUT OF WLFILTERS ACTIVE THIS YEAR
11mysql:research@s3-analytics-slave [enwiki]> select count(user_id) from user inner join user_properties as upl on user_id=upl.up_user and upl.up_property='wllimit' and upl.up_value in (0, '0') inner join user_properties as upd on user_id=upd.up_user and upd.up_property='watchlistdays' and upd.up_value in (0, '0') inner join user_properties as upr on user_id=upr.up_user and upr.up_property='wlenhancedfilters-disable' and upr.up_value in (1, '1') where user_touched >= 20180101000000;
12+----------------+
13| count(user_id) |
14+----------------+
15| 1 |
16+----------------+
171 row in set (6.87 sec)
18
19-- USERS WITH LIMIT>0, DAYS=0 WHO HAVE OPTED OUT OF WLFILTERS ACTIVE THIS YEAR
20mysql:research@s3-analytics-slave [enwiki]> select count(user_id) from user inner join user_properties as upl on user_id=upl.up_user and upl.up_property='wllimit' and upl.up_value > 0 inner join user_properties as upd on user_id=upd.up_user and upd.up_property='watchlistdays' and upd.up_value in (0, '0') inner join user_properties as upr on user_id=upr.up_user and upr.up_property='wlenhancedfilters-disable' and upr.up_value in (1, '1') where user_touched >= 20180101000000;
21+----------------+
22| count(user_id) |
23+----------------+
24| 1 |
25+----------------+
261 row in set (0.02 sec)

We looked at users who had opted out of new filters, because anyone with new JS filters would have a functional watchlist (and updated preference values) as soon they began adjusting the days/limit values in the UI.

To recap what the problem is: if you have 0 for watchlistdays and 0 for wllimit in your preferences, and you use the old watchlist interface, then loading your watchlist shows 0 results. And if you change "Days to show" on Special:Watchlist, the wllimit in the preferences isn't overridden so you'll still see zero results.

As far as we can tell, there aren't any users who fit into this category (limit = 0, max days = 0, opted out of new filters), so we don't think we need to bring back the "0 = maximum value" logic.

Instead we are proposing to:

  1. update the preferences text with "Minimum value 1, maximum value {max limit variable}"
  2. require a value of 1 or higher for both number of days and changes to show.
kostajh triaged this task as Normal priority.Sep 6 2018, 2:37 PM
kostajh edited projects, added Growth-Team (Current Sprint); removed Growth-Team.

Change 458517 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/core@master] Watchlist preferences: Disallow zero value for days/limit

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

Change 458517 merged by jenkins-bot:
[mediawiki/core@master] Watchlist preferences: Disallow zero value for days/limit

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

dasime added a subscriber: dasime.Sep 8 2018, 5:09 PM
Etonkovidova added a comment.EditedSep 17 2018, 10:06 PM

@kostajh @MMiller_WMF Preferences-Watchlist shows the warning as the follow:


The minimum value is set to:

$defaultPreferences['watchlistdays'] = [
			'type' => 'float',
			'min' => 1 / 24

Can we display it to a user in more user-friendly way?

Can we display it to a user in more user-friendly way?

@Etonkovidova not that I can think of at the moment. I will follow up in T204623 but I would recommend not showing this preference at all if the user has not opted out of the new style watchlist / RC filters.

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

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

MMiller_WMF closed this task as Resolved.Oct 2 2018, 12:25 AM
MMiller_WMF moved this task from Needs PM Review to Done on the Growth-Team (Current Sprint) board.