Page MenuHomePhabricator

Implement a namespace filter for the logging table
Open, LowPublic

Assigned To
None
Authored By
bzimport
Jul 3 2008, 5:23 PM
Referenced Files
None
Tokens
"Love" token, awarded by IKhitron."Like" token, awarded by Wnme."Like" token, awarded by MGChecker."Doubloon" token, awarded by Scott.

Description

Author: Wiki.Melancholie

Description:
Special:Log/... does not have a namespace filter like other special pages.


URL: http://en.wikipedia.org/wiki/Special:Log

Event Timeline

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

ayg wrote:

Note that you can already filter Special:Log by page prefix, which could easily include filtering just by namespace (although it currently doesn't). This functionality is disabled on Wikimedia wikis for performance reasons. I can't recall what the rationale was for that, and no comment explains why $wgMiserMode is used, so I don't know if it would apply to namespace filtering.

Bug 14712 could be related: the list=logevents API module used to have an lenamespace parameter, but I removed it because Aaron Schulz reported the associated database queries were slow.

ayg wrote:

Thinking about it, I see the reason. You can't use the index for sorting if you retrieve by prefix. It has to either be filesorted, or retrieved from some other index like log_timestamp and filtered. So that won't be able to run acceptably, no, not without another index on (log_namespace, log_timestamp), and you'd have to have all sorts of other tiresome permutations to get namespace filtering to work well in conjunction with others. This is fine to add as an improvement for the page prefix filtering, but it's not going to be able to run on Wikimedia. (Now let me add a comment to that code.)

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

RSYQFIOJGWZA wrote:

It has been almost three years since this bug was filed. Have Wikimedia wikis' performance increased sufficiently to revisit this bug?

ayg wrote:

It's not about "Wikimedia wikis' performance", it's about how indexes work in MySQL. The performance considerations I discuss in comment 3 have not changed in several years and are unlikely to change for the foreseeable future.

RSYQFIOJGWZA wrote:

(In reply to comment #1)

Note that you can already filter Special:Log by page prefix, which could easily
include filtering just by namespace (although it currently doesn't). This
functionality is disabled on Wikimedia wikis for performance reasons.

Is the ability to filter Special:Log by page prefix still "disabled on Wikimedia wikis for performance reasons"? If so, is the reasoning behind it being disabled still sound? Thanks.

(In reply to comment #7)

(In reply to comment #1)

Note that you can already filter Special:Log by page prefix, which could easily
include filtering just by namespace (although it currently doesn't). This
functionality is disabled on Wikimedia wikis for performance reasons.

Is the ability to filter Special:Log by page prefix still "disabled on
Wikimedia wikis for performance reasons"? If so, is the reasoning behind it
being disabled still sound? Thanks.

Yes and yes, per comment 6

  • Bug 27709 has been marked as a duplicate of this bug. ***
  • Bug 28487 has been marked as a duplicate of this bug. ***
  • Bug 29139 has been marked as a duplicate of this bug. ***

Can we please get some progress on this? you cannot filter per namespace.Try searching for just mainspace deletions.... You cant. Try using the prefix: Template: you dont get template space deletions.

The advanced review log of FlaggedRevs has a namespace filter, see QualityOversight_body.php. It uses what is described as a "cutoff time (mainly for performance)". Looks like it can be adapted for the deletion logs and others, doesn't this solve the performance issue ?

The advanced review log also filters for action type. Doing the same would be useful for other logs, e.g. to sort between deletions, undeletions and selective deletions - see T19806. A general namespace filter for Special:Log wouldn't make sense in my opinion, since many logs aren't tied uniquely to a namespace. Instead, I would suggest an 'advanced log' special page for each of the deletion, protection, block and move logs. This way, each log type would have the most relevant options.

Move is a bit tricky, though, since we need the namespaces for both source and target page. The target title is hardcoded in log_param, so its namespace could be retrieved from there. But what of the namespace of the source page ? We'd better not use the page id, since the page may have been moved again and changed namespace, plus it became the id for the moved page in T59084. I'm not sure which one is returned by log_namespace ?

Every way to examine changes made to the database (edits, deletions, etc.) should be filterable by namespace. Being able to filter Special:Log/delete by namespace is particularly useful for improving the accountability of administrators.

A workaround the performance issues would be to create an autotag for "deletions in mainspace", similarly to the autotags for redirects and such of T73236.

Looks like this is already possible with the logevents API. So I guess the performance issue is no longer a concern and this is only about exposing it on Special:Log now?

Change 135284 had a related patch set uploaded (by Glaisher):
Allow filtering log entries by namespace (Special)

https://gerrit.wikimedia.org/r/135284

@Glaisher Is there any progress with this task?

@Cenarium @Jackmcbarn Is there any progress on this? I think this is an incredibly useful feature and it would be a pity if it's nearly done, but never completed.

I got here and realised this bug is seven years old. It would be great to solve this some day ...

(Apologies all for bugspam)

@Paucabot if you look right at the top you can see that this bug was actually imported from the old bug tracker in 2008. It does seem like functionality that could be adapted relatively easily from somewhere else in the code, although I'm not a dev so can't say that for sure. Either way, if you're on EnWP, you could try posting about it on WP:VPT and maybe there'll be someone interested in contributing a patch - commenting here isn't likely to lead to any progress.

Ok. I'll try elsewhere, but precisely I came here because I thought it was the right place.