Are you wanting the value of wl_notificationtimestamp ?

mk45654 wrote:

(In reply to comment #1)

Are you wanting the value of wl_notificationtimestamp ?

Yes.

And also to set the value, using e.g.

api.php ? action=watch & title=Main_Page & notificationtimestamp=...

where notificationtimestamp is an optional parameter. This would allow user scripts to set pages read/unread, or otherwise use the value.

r61730 adds the ability to get wl_notificationtimestamp

[22:50:42] <Reedy> RoanKattouw: for the 2nd part of that bug.... Should they be able to set it to whatever the hell they want? :/
[22:51:10] <RoanKattouw> No, absolutely not
[22:51:12] <RoanKattouw> WONTFIX
[22:51:29] <Reedy> Well, the bugs half fixed
[22:51:33] <RoanKattouw> Don't mess with internal database stuff kthx
[22:51:41] <RoanKattouw> Well that part of the bug is WONTFIX :)
[22:51:55] <Reedy> yeah... I did think it seemed weird

No chance of being able to set the value via the API

mk45654 wrote:

Great, thanks for the first part.

Still, the API should offer write. Messing with internal database stuff is the purpose of an API. I understand Roan's concern: you don't want to let the user access e.g. their signup date. But I see no reason why the user should be unable to have control of this field. It is there for the user's convenience, and no other user or process cares what its value is. The use cases are as follows:

1. A user script needs to visit several pages or diffs without resetting notificationtimestamp, since resetting the timestamp might cause the user to miss vital changes, or be swamped by repetitive emails. The API (iirc) offers no provision to visit without resetting. The script therefore stores the current value, visits the diff, and resets the value.

2. A user script needs to intentionally reset notificationtimestamp. Whenever the user opens their watchlist, the script checks if all intervening changes were vandal-reverts, and resets the timestamp if they were (i.e. it automatically marks watchlist items read according to certain criteria).

3. A user checks a page, but realizes that they don't have the time to read through the changes now. A user script allows them to mark that revision "unread" by resetting the timestamp to its previous value.

4. A user feels that a edits and talk-page discussion is getting too heated on a certain page, and would like to take a break from it. A user script allows them to set the notificationtimestamp for 1 week into the future, which prevents the offending page from appearing on their watchlist.

(I haven't looked at this for a while, so I may be mistaken in treating notificationtimestamp as a "lastseen", though these cases can be reworked to fit.)

The notification timestamp is not quite a 'last seen' timestamp, it's the timestamp of the first unread revision, or NULL if there are none. I'm vary of allowing users to set it to any old value because I don't know what will happen when its value is invalid (lemme look that up).

Use case #1 concerns screen scraping while getting page contents and diffs is possible through the API (I'm pretty sure this doesn't touch wl_notificationtimestamp). If your screen scraping unnecessarily and these kinds of issues come up, they're your problem.

Use case #2 sounds valid ('mark as read'). It can easily be done by visiting the page in the background with AJAX, although I agree that's a hack and the API should offer a 'mark as read' feature. That, however, would set the timestamp to NULL, not to an arbitrary client-provided timestamp.

Use case #3 is a good one. I think this feature should be in core and exposed through the UI as well as the API.

Use case #4 is based on a misunderstanding of what the notificationtimestamp does: setting it in the future will not prevent it from showing up in the watchlist, it'll just show it as having been changed in the future and confuse the code showing you the diff.

I'll reopen this bug for use case #2, and I suggest you open a new one for #3 (specifically for the mark as unread feature to be available in core).

Yeah, that makes sense - Marking as "read" and setting to null.

Oh, where are we sticking it?

https://gerrit.wikimedia.org/r/#/c/11965/

I agree with Roan regarding the cases from comment 5. Although I note that a "mark unread" feature in core might well use the API via ajax to do the marking, like the watch/unwatch tab does now.

To add to case 2, personally I want to be able to add a "seen" button to the watchlist lines. But I'm concerned that I might load my watchlist, spend 20 minutes reading changes to other pages, and then click "seen" on a page and lose notification of the edits to that page made during the 20 minutes I was doing other stuff. This is the reason I never use the existing "Mark all pages visited" button on the watchlist. So I'd ideally code my "seen" button to say "set wl_notificationtimestamp to just after revision X".

As for setting wl_notificationtimestamp to invalid values, it appears that it's either treated as a boolean "changed" value (e.g. for watchlist bolding) or compared against the revision timestamp using >= (e.g. for recentchanges or history highlighting). So as long as it's a valid timestamp it shouldn't matter what specific time it is set to.

In gerrit change 11965, I took the approach of using the ApiPageSet module so multiple pages can be marked at once, if desired. For convenience in my desired use case, I allow selection of the timestamp (for a single page) by passing a revision id so it's not necessary to do a separate query to prop=revisions just to find the necessary timestamp.

gerrit 11965 is successfully merged