Page MenuHomePhabricator

Logs about watched pages should appear in the watchlist and recentchanges
Closed, ResolvedPublic

Description

Author: marco

Description:
As [[bug 861]] tells us, MediaWiki now records page blocks in the page history.
Why the don't appear in the watchlist then?


Version: unspecified
Severity: enhancement

Details

Reference
bz5546

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:10 PM
bzimport set Reference to bz5546.
bzimport added a subscriber: Unknown Object (MLST).

The watchlist works from the recentchanges table.

Currently that includes the log entries, but may not be including the
history entries.

robchur wrote:

(In reply to comment #1)

Currently that includes the log entries, but may not be including the
history entries.

It doesn't. The null edit used is not "notified" as a recent change.

  • Bug 7790 has been marked as a duplicate of this bug. ***

The NS and Title for log items in Recent Changes is that of the log, -1 and
"Log/rights" for example. The actual NS and title of the page in question is not
stored however. That info is only in the summary wiki text, along with other
unwanted text.

We should just use rc_type only to denote logs perhaps. That way, rc_namespace
and rc_title can be that of the relevant page, rather that the -1,log/something.
This would allow watchlists to pick it up with a small watchlist query change,
that is use "OR rc_timestamp > page_touched" (for logs events). This is because
the "is this the top edit" makes no sense for log items. This could result in
several events showing on the watchlist for one page, but that is somewhat
unavoidable.

RecentChanges row lines might need some modification on their behavoir, so that
they say "(logs)" in front of them for any rc_type=RC_LOG, rather than the page
name. It would be something like:

(Logs); 08:18 . . Voice of All (Talk | contribs | block) (protected "Freedom
Tower": test [edit=autoconfirmed:move=autoconfirmed])

Otherwise it would show like:

(diff) (hist) Freedom Tower 08:18 . . Voice of All (Talk | contribs | block)
(protected "Freedom Tower": test [edit=autoconfirmed:move=autoconfirmed])

robchur wrote:

It would be nice not to have to regress in terms of the links we provide - I'd
like to see the individual logs distinguished as they are now.

I don't mind it just saying (log), since that link is minimally useful, where as
allowing events to watched pages to show is more useful IMO. The above changes
would avoid a table change.

Nevertheless, with a table change, we might as well swap the rc_namespace and
rc_title for logs witht that of the relevant page, and store the log NS (-1) and
title to another 2 columns. If we are doing this, then I'd like to see
user_agent header info added as a 3rd column per bug 8290 while we're at it.

*** Bug 4898 has been marked as a duplicate of this bug. ***

  • Bug 4898 has been marked as a duplicate of this bug. ***

robchur wrote:

*** Bug 8969 has been marked as a duplicate of this bug. ***

robchur wrote:

*** Bug 9189 has been marked as a duplicate of this bug. ***

robchur wrote:

*** Bug 881 has been marked as a duplicate of this bug. ***

Just an administrative-related comment (or maybe a feature request for Bugzilla): is it a good idea to mark an
older bug with 25 votes as a duplicate of a newer bug (without all those votes)? (Not that voting would mean
anything really relevant in MediaZilla.)

robchur wrote:

(In reply to comment #13)
This bug covers the general problem and contains better discussion on technical
solutions.

robchur wrote:

Please don't fix unrelated bugs in a big merge again; it makes it near
impossible to review the code. Open a separate branch to make separate changes
like that.

wiki.bugzilla wrote:

*** Bug 9452 has been marked as a duplicate of this bug. ***

robchur wrote:

(Branch merge was reverted, reopening)

hardy wrote:

I think this should be treated as urgent. Those who spend most of their time
deleting pages are extremely militant and some of them are extraordinarily
hostile to the idea that one should consult persons knowledgeable in a
particular field to find out what is considered notable before deleting a page.
If a page on my watchlist is deleted, I don't find out about it when I look at
my watchlist.

Couple of notes:

  1. It's not super-urgent, since it's been like this for a long time.
  1. Implementation is currently waiting on a database schema change for the

recentchanges table; schema changes are in progress now, should be live in a
couple more days. Then implementation can go ahead.

  • Bug 9689 has been marked as a duplicate of this bug. ***

le.korrigan wrote:

It seems that the database schema change has gone live, now. Can this bug be fixed or is there anything else blocking it ? Thanks.

ayg wrote:

*** Bug 10695 has been marked as a duplicate of this bug. ***

  • Bug 10986 has been marked as a duplicate of this bug. ***

MediaWiki wrote:

I'd like to see this, as well. It would be quite useful.

  • Bug 11750 has been marked as a duplicate of this bug. ***

*** Bug 12062 has been marked as a duplicate of this bug. ***

ayg wrote:

*** Bug 12046 has been marked as a duplicate of this bug. ***

  • Bug 12376 has been marked as a duplicate of this bug. ***
  • Bug 12375 has been marked as a duplicate of this bug. ***

gangleri wrote:

added « and recentchanges » to the summary

the summary of the duplicate was
bug 12375 the namespace=6 (image) filter at « special:Recentchanges » should include the page creation events from « special:upload »

Created attachment 4736
Half-done code to use the new RC fields

Some issues with block grouping in enhanced RC view still; more worrying is that the log entries still aren't showing in WL though they should. Bah.

Attached:

catlow wrote:

Is this supposed to be working on en.wikipedia? I'm still not seeing page moves on my watchlist, for example.

robert wrote:

Modifications done to the core code are usually synchronised daily with the code used on Wikipedia, but this is taking longer due to configuration issues. It might be synchronised within the next week or two, maybe.

  • Bug 13654 has been marked as a duplicate of this bug. ***

catlow wrote:

(Further to previous comments, I see this *is* now working on en.wp.)

  • Bug 15038 has been marked as a duplicate of this bug. ***