Page MenuHomePhabricator

Provide special page/API call to list watchlist along with "notification statuses"
Closed, InvalidPublic

Description

Debugging issues like T110850 is hard because the user can only determine that he is affected by such an issue usually some time after the fact, and either log files may have been purged or there is the underlying question how reliable a user's claim is that he indeed did not receive a mail several weeks or months ago.

To make that easier, there should be a special page or an API call that lists the pages on the watchlist along with their "notification statuses", i. e. whether when the particular page is changed, the user will be notified. https://www.mediawiki.org/wiki/Manual:Watchlist_table#wl_notificationtimestamp says:

This is the timestamp of the first change to the page made by another user after the last visit by the watching user; the timestamp is cleared when the user visits the page. When the timestamp is updated, notification email may be sent.

The timestamp is always cleared (made NULL) when the user visits the page, whatever their personal settings, as long as either either of $wgUseEnotif or $wgShowUpdatedMarker is true.

One simple idea would be to mark up page titles on https://en.wikipedia.org/wiki/Special:EditWatchlist that have not been visited as bold.

At least for my non-debugging use case, even better would be a special page that lists all unvisited pages with links for the diff since the last visit.

Event Timeline

scfc raised the priority of this task from to Needs Triage.
scfc updated the task description. (Show Details)

With api query action watchlist you can receive the notification timestamp for you watchlist or with prop=info for a set of titles. But notification timestamp is set before sending emails, so not helpful for debugging.

https://en.wikipedia.org/w/api.php?modules=query+watchlist
https://en.wikipedia.org/w/api.php?modules=query+info

scfc claimed this task.

The API queries are exactly what is needed; I should have guessed that the information was already exposed.

I think for debugging it is helpful, because the notification timestamps indicate when a mail should have been sent; and if none arrived, either because no mail was sent or it got lost somewhere along the way, that's a useful hint for further investigation.

This wouldn't help confirm or debug the particular problem I experienced.

In my case, notification emails for a Wikipedia page started again for no apparent reason, although it was probably because I had visited the page while logged-in. (See https://phabricator.wikimedia.org/T110850.)

When I checked the page, I saw that there had been many changes over the previous 6 months or so, none of which I had received emails about.

I looked back at the earlier emails I had received, and I felt I was sure I had logged-in to check the changes after I received the email, yet notifications emails had stopped.

The api only gives the latest timestamp, so wouldn't help confirm or debug my problem.

As mentioned on task T110850, if there were a problem with notification emails, no-one might believe the reporter, because they would suspect the reported hadn't visited the page in question while logged-in.