Page MenuHomePhabricator

Mobile Watchlist does not take into account preference value of expand/aggregation into account
Closed, DeclinedPublic

Description

By default, the mobile watch list uses the "Expand watchlist to show all changes, not just the most recent" mode of the watch list, even if not so selected in the preferences of the user.

This is inconsistent with the website and might be confusing. Also it means that busy pages take up an extraordinary amount of items in the watch list, making it easy to miss changes on other pages.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68368
https://bugzilla.wikimedia.org/show_bug.cgi?id=68369

Details

Reference
bz68367

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:37 AM
bzimport set Reference to bz68367.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/KpdIlK5i

Change 149326 had a related patch set uploaded by Jdlrobson:
WIP: Make mobile watchlist use core code

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

Jdlrobson added a project: MediaWiki-Watchlist.

Patch was abandoned. We need to refactor core Watchlist code to support mobile use case.

We don't have capacity to reimplement the watchlist anymore then we currently have. The problem with the current implementation is it directly hits the database rather than making use of an api method provided by core to access to all rows in the watchlist. It thus overlooks things like preferences. Continuing like this is unsustainable.

I will make sure this particular feature is added as a requirement to T109277 which aims to increase code quality of the special watchlist code in core to allow it to be skinned for mobile. At very least that work should give us an api/model of the data in the watchlist and simply override the presentation.

Please bear with me a week or so to do this.
Ps. Not sure if declining or merging as duplicate was appropriate here.