--- Comment #5 from mk <mk45...@gmail.com> 2010-01-31 00:20:17 UTC ---
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
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
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
Wikibugs-l mailing list