Page MenuHomePhabricator

After switching patrolling off, impossible to effectively hide patrol log entries in Special:Log
Open, MediumPublic

Description

Sometimes a wiki has patrolling on and then decides it's not useful for their purposes and turns it off. This results in a whole lot of patrol log entries that most nobody wants to see suddenly becoming visible in the log with no way to effectively hide them. (Because apparently the filtering thing $wgFilterLogTypes doesn't apply to it anymore, or something, though you can still select it in the dropdown as a type to only show.)

It's kind of annoying, although obviously not something that would come up often.

But when it does it's kind of annoying.


Version: 1.23.0
Severity: normal

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:45 AM
bzimport set Reference to bz42246.

Hmm, I guess its some sort of performance optimization

if( $type !== 'patrol' || $this->getUser()->useNPPatrol() )

So it does disable filtering out patrol logs if patrolling is disabled.

Even more concerning, it stops the filtering if the user doesn't have patrol rights. For example, anons (in some configs) will have the filtering disabled. This can be verified by looking at [[w:Special:log]] as an anon vs as a logged in user (not too many entries as WP only uses new page patrol).

gerrit change 42279

This isn't perfect though. Ideally we wouldn't have the "show patrol" link there if patrolling is disabled since that's mostly useless, but I think that's better then having the logs flooded with patrol entries when a wiki disables that feature.

(In reply to comment #2)

This isn't perfect though. Ideally we wouldn't have the "show patrol" link
there if patrolling is disabled since that's mostly useless, but I think
that's
better then having the logs flooded with patrol entries when a wiki disables
that feature.

It definitely is not better, in my opinion. Rather than ruining most wikis for the sake of a handful of volatile ones, this should be governed by a configuration variable which can be turned on in those rare cases, shouldn't it?

(In reply to comment #3)

(In reply to comment #2)

This isn't perfect though. Ideally we wouldn't have the "show patrol" link
there if patrolling is disabled since that's mostly useless, but I think
that's
better then having the logs flooded with patrol entries when a wiki disables
that feature.

It definitely is not better, in my opinion. Rather than ruining most wikis
for
the sake of a handful of volatile ones, this should be governed by a
configuration variable which can be turned on in those rare cases, shouldn't
it?

It already is. People can always remove patrol from $wgFilterLogTypes. However, patrol is in there by default.

I don't think its a big issue, because having a very small link doesn't exactly ruin things for other wikis.

(In reply to comment #4)

I don't think its a big issue, because having a very small link doesn't
exactly
ruin things for other wikis.

It does. Confusing meaningless clutter is definitely something we shouldn't add on purpose, while all the MediaWiki development efforts are (hopefully) in the opposite direction.

We could instead have 'patrol-if-enabled' added to $wgFilterLogTypes in DefaultSettings.php, and then have Setup.php change that value to patrol if it is present and patrolling is enabled, and remove that value otherwise. However that seems hacky...

Or $wgFilterLogTypes could just be manually set as appropriate by the wiki in need of it...

(In reply to comment #7)

Or $wgFilterLogTypes could just be manually set as appropriate by the wiki in
need of it...

Brian, if you agree with the above you could change the summary of this report so that it covers only the actual bug you found:

(In reply to comment #1)

Even more concerning, it stops the filtering if the user doesn't have patrol
rights. For example, anons (in some configs) will have the filtering
disabled.

And I could file a bug for $wgFilterLogTypes to be set on our wikis where relevant, update docs to say this is the right thing to do etc.

(In reply to comment #8)

(In reply to comment #7)

Or $wgFilterLogTypes could just be manually set as appropriate by the wiki in
need of it...

Brian, if you agree with the above you could change the summary of this
report
so that it covers only the actual bug you found:

(In reply to comment #1)

Even more concerning, it stops the filtering if the user doesn't have patrol
rights. For example, anons (in some configs) will have the filtering
disabled.

And I could file a bug for $wgFilterLogTypes to be set on our wikis where
relevant, update docs to say this is the right thing to do etc.

I changed my patch. After thinking about this for a day - I think it does make sense to have the automatic behaviour match the current, but users should be able to override in LocalSettings.php (basically did what I said in comment 6).

So now the patch keeps the exact same behaviour as before, except if you set $wgFilterLogTypes['patrol'] = true in LocalSettings.php it will enable the filtering even if patrol is disabled. And anons can now filter special:log to remove patrol

Change 42279 had a related patch set uploaded by Nemo bis:
(bug 42246) allow hiding patrol entries from main Special:log

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

Change 258413 had a related patch set uploaded (by Cenarium):
Allow unused log types to be hidden by default

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

Note that the same applies, to a lesser extent in terms of volume, to the unused log types of Article Feedback at enwiki, FlaggedRevs logs at mediawiki.org, and many others. To a certain extent, it's worse since they're no longer formatted.
Hence the general system I've introduced in https://gerrit.wikimedia.org/r/258413.

Hence the general system I've introduced in https://gerrit.wikimedia.org/r/258413.

Interesting. However a checkbox (if I understand correctly) seems overkill: it would produce noise for everyone, even people who never get to see such log entries. Better would be another dropdown option like "All public logs (including unused logs)", IMHO. No idea how hard.

Hence the general system I've introduced in https://gerrit.wikimedia.org/r/258413.

Interesting. However a checkbox (if I understand correctly) seems overkill: it would produce noise for everyone, even people who never get to see such log entries. Better would be another dropdown option like "All public logs (including unused logs)", IMHO. No idea how hard.

The drop down menu is for the log type and it would require some kind of hack to get around this. If the checkbox is too intrusive, then we might just leave it as a url param.

Change 384197 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/core@master] No longer special case 'patrol' in $wgFilterLogTypes

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

Change 384197 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/core@master] No longer special case 'patrol' in $wgFilterLogTypes

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

Seems a straightforward improvement indeed, but I've not tested.

Change 384197 merged by jenkins-bot:
[mediawiki/core@master] No longer special case 'patrol' in $wgFilterLogTypes

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

@Bawolff: Hi, I'm resetting the task assignee due to inactivity. Please feel free to reclaim this task if you plan to work on this - it would be welcome! Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for more information - thanks!

Change 258413 abandoned by TTO:

[mediawiki/core@master] Show only valid log types in logs

Reason:

Was fixed another way: see for instance https://en.wikipedia.org/w/index.php?title=Special:Log&logid=80132333

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