Page MenuHomePhabricator

For pages on watchlist save last seen version number
Closed, DeclinedPublic

Description

Author: jens

Description:
It would be nice if (at least) for pages on the watch list, MediaWiki would
store per-user information about what specific version this user last saw.

Update of this information might happen if the user specifically requests it,
and not every time he visits that page.

This would make possible a new kind of watch list view: sorted by the number of
times that page has been updated since the user last inspected it.

There should be a link on that watchlist page which shows the diff between the
stored version number and the current version that at the same time updates the
information in the database (see paragraph 2).

This would make the watchlist much more useful.

For privacy reasons, each user should have to explicitly activate that feature,
because the information which version of a page (and thus, when) he visited is
sensitive personal information.

This depends on bug #181 because the ID of the current version needs to be stored.


Version: 1.5.x
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/Email_notification_versions

Details

Reference
bz536

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:56 PM
bzimport added a project: MediaWiki-General.
bzimport set Reference to bz536.
bzimport created this task.Sep 20 2004, 9:20 AM

rowan.collins wrote:

This (or at least the "diff to last seen" link) is apparently implemented as
part of the "ENotif" patch (see bug 454). Also, note that the privacy issue
seems to me a non-issue, since the entire watchlist is only visible when logged
in - i.e. nobody but you can see what you're watching, let alone when you last
visited it.

[Marking bug 454 as a dependency, since that seems the most appropriate
relationship available.]

I only want to suggest and to introduce the abbreviation "LVR" or (lvr) which
stands for "last visited revision".

This would facilitate my further program development (enotif =
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ), in which I can simply(!)
add a THIRD link in the recent changes, page history and watchlist views
(currently for WATCHLISTed pages only, as Enotif only keeps track of pages in
the watchlist of somebody, and of user_talk pages).

A suggested slightly modified RC line could look like this example:

(diff)(hist)(diff-this-to-lvr) page_title_of_a_watched_page(this revision)

pageeditor(talk) .......

(diff-to-lvr) is self-explaining, isn't it ? It shows a watching user(=you) the
difference between this revision and your (lvr).

Be reminded, that Enotif > 1.32 mails are already(!) sent out with a direct link
to the (diff-cur-to-lvr), the difference view between the current (cur) version
of a page and your (lvr).

So if you are interested in trying this feature, download my Enotif 1.33. This
nice feature was proposed to me by Chris Phoenix and it was easy to implement.

Tom

I added a link to my two screenshots (RC view and Page History) on one of the
Enoitf documentation pages
http://meta.wikimedia.org/wiki/Email_notification_versions , so that you can see
it without actually installing Enotif now.

The screenshots show in reality, not as a mock-up, the so-called "updated (since
my last visit)" markers - which tell the watching user what revisions bear new
contents. Again: these flags are only shown for watch-listed pages.

Thus everyone will understand, that the (lvr) - last visted revision - is just
the version *before* the updated marker starts provoking you reyes. (The actual
layout of the marker can be changed - this beamy layout is just a beginning).
Enotif knows the (lvr) revision and sends you a link with the enotif mail.

Everyone can make use of the updated markers, because these are shown
*independently* from sending enotif mails to you. For example, you can have all
enotif mails disabled in your user preferences (you will never get enotif mails
on page changes), but you will see the updated markers for the not-yet-visited
revisions of watched pages. Once you visit the current version, the
corresponding marker is cleared. A further page change of someone else would
trigger again an(one) Enotif mail to you - but only if you have enotif mail
enabled - and an "updated" marker is shown again.

If you don't want to see the updated markers at all, you can disable these in
other user preference option. The markers also work smoothly in the so-called
Enhanced RC view.

The mechanism and option of Enotif are explained on
http://meta.wikipedia.org/Enotif (I repeat myself, pls. apologise).
Tom

Created attachment 117
Enotif 1.33 implements this with a beamy "updated (since my last visit)" marker

The updated markers of Enotif 1.33 are not only shown in the page history view
as in the accompanying screenshot, but are also shown on the recent changes
view and the *watchlist*, as suggested in this bugzilla-536 title.

Attached:

I took over to implement this. Easy (trivial) with Enotif. Tom

(is it okay, that I assigned this to me, and that I put wikibugs-l@wikipedia.org
into the CC ?)

Introducing an incomprehensible acronym is not a good idea.

You are too pushy for me, when you simply delete another point of view. Please
tell me and the community a better acronym instead of simply deleting my
proposal, thanks. We already have (hist) and (diff), so we need a short and
better name for such links, which are proposed by very kind and friendly
proposers. What is your proposal, I kindly ask.

My proposal - now withdrawn - was : (last-visited-revision) or short: (lvr)

Any recent page line could have - according to MY PERSONAL POINT OF VIEW - these
three links

(hist) (diff) (lvr)

On any RC page footer, a short explanation would explain even the short-sighted
users that (lvr) stands for (last-visited-revision)
If you have any better proposal, I am looking forward to it. Any proposal will
be better than simply a NO-PROPOSAL by deleting something.

I KINDLY invite all members of the wikibugs-list to come up with a CUTE proposal
for a shorter name for such links. I fully understand, that I cannot butcher the
RC view or other view with a personally introduced name. This is also not my
intention, and I and Jens Müller need all your help.

So repeated again:
Please all native English speakers and others, please contribute a cute and
short name for such links

(diff) (hist) (YOUR PROPOSAL)

bugzilla536 title addition deleted by the proposer(myself) to avoid any flaming
here. I need to work with it today.

Again: be courageous and tell me your proposal for a short and concise name for
links (in Recent Changes View), which unambiguously describe even for dumb users
a link to the "last seen version number" or how I call it, the "last visited
revision".

(hist) (diff) (??????) Page_title

I like both names, but we need something SHORT to be put onto the restricted
area of the recent page view page.

My ad-hoc proposal: (lvr) plus an explanation on every page, that lvr stands for
"last visited revision".
If you have a better one: please let me know.

Tom, there are several big problems with abbreviations and acronyms.

First, they are confusing for newbies and non-native speakers, to whom the terms may be completely unclear. A little message squirreled
away on the page will generally not be read.

Second, there's an internationalization issue: these terms need to be translated for each language the interface is presented in. When new
ones are added, this creates a maintenance burden as the terms must be translated into many languages. Every language needs to come up
with not only a term, but a legible abbreviation of it; there may be significant variations in the length of the chosen translation which affects
the layout of the user interface (see next).

Third, all this has to be fit into the user interface. Especially when page titles, usernames, or comments are very long, this can end up
producing a list that's very hard to read, as text haphazardly breaks and wraps. Adding new things to the output makes it progressively worse.

Please don't think that we all hate you personally; rather consider the general problem.

All enotif versions > 1.33 have this implemented: a beamy "updated (since my
last visit)" marker

The updated markers are not only shown in the page history view as in the
accompanying screenshot, but are also shown on the recent changes view and the
*watchlist*, as suggested in this bugzilla-536.

I can only repeat, that interested users should check out my new Enotif 2.00 for
CVS 1.5 see http://bugzilla.wikipedia.org/show_bug.cgi?id=454 (use the latest
tgz file in my latest comment. The diff files do not have all additional update
files in it, because diff does not store or compare my local files, which were
not in the CVS)

( implementation detail for interested readers:
because there are no "sticky version" numbers yet which survive delete/undelete
cycles - see other bugzillas - its implemented indirectly via the
wl_notificationtimestamp in table watchlist, which stores the time, when a
user has got a notification email for a page change of another user. The version
of a page exactly before that timestamp is the "last visited revsion (lvr)" of
that page, for this watching user. )

  • this is fixed using a timestamp (not using a sticky version number). COuld be

regarded as closed -> close.

I reopened this.

There was a recent comment to http://bugzilla.wikipedia.org/show_bug.cgi?id=603
(delete/undelete cycle doesn't preserce old_id) which bug I have overlooked when
closing the 536.

I am currently working and have almost finished the implementation of a direct
link to the

(diff-to-last-visited-revision)  short: diff-to-lvr

of watched pages. This is just another valuable exploit of my ENotif patch
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ; it requires a new column
wl_lastvisitedrevision (lvr) in the database table watchlist. I have already
written the necessary conditional database updating code for the updaters.inc
module.

Implementation detail: the lvr is already retrieved during page views of watched
pages and since now stored together with the ENotif timestamp in the new
separate database column.

People who are interested in this patch can ask me for the diff of my patch.

The new (diff-to-lvr) links are only shown for one's watched pages, because only
watched pages have entries in table watchlist to cache the "old_id". Old_ids
currently do not survive delete/undelete cycles, but this will change at some
later time; the patch is working fine as long as the old_id is not changed,
which is the case if no delete/undelete cycles are performed.

As with ENotif, only "alien" changes influence these links; if there is an
"updated (since my last visit)" marker, than a (diff-to-lvr) makes sense and is
shown; otherwise none of the latter are shown. It means for a watching user:
there are no unknown changes on this watched page.

The patch works independently from the user options of enabling or disabling the
ENotif mails to be sent. With other words, you might choose never to receive
ENotif mails but you see the "updated" markers and (diff-to-lvr) links on
not-yet-visited pages you are watching.

(Lengthy, but hopefully clear explanation.)

Wikinaut Tom

Implementation of this enhancement needs one additional field in table watchlist.

ALTER TABLE /*$wgDBprefix*/watchlist ADD (wl_lastvisitedrevision int(10)
unsigned NOT NULL default '0');

The patch is short and will be published including the updaters.inc script soon.
A third link is shown - in addition to (diff) (hist) links on Recent Changes
views - for those pages, which are _watched_. This third link brings you
directly to the difference view of the diff(current ./. your last visited revision).

It was a long-felt need of many users.

brian wrote:

(In reply to comment #1)

This (or at least the "diff to last seen" link) is apparently implemented aspart of the "ENotif" patch (see bug

454). Also, note that the privacy issueseems to me a non-issue, since the entire watchlist is only visible when
loggedin - i.e. nobody but you can see what you're watching, let alone when you lastvisited it.[Marking bug 454 as a
dependency, since that seems the most appropriaterelationship available.]

I think there are plenty of people who will not think that this is a non-issue. The issue we normally look at is not
who is *supposed* to have access to this information (security could be better - using HTTPS, for example), but
rather whether another person or organisation is collecting the information.

brian wrote:

(In reply to comment #17)

This is probably the wrong place to discuss this, but just to clear up the previous comment, which was a little confusing...

What I meant was: I think there are plenty of people who will think that collecting personal information *is* an issue, even if no humans are supposed to have access to that information. I also mentioned that it would be better to use HTTPS (to be fair, they do have a secure server, but I'm suggesting that certain pages be secure by default without having to manually type in an address starting with "https").

There's also the issue not mentioned before, which is that developers do have access to personal information.

Assumes that rev_id is in order. Due to merges/imports, timestamps are better.