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

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

bzimport added a project: MediaWiki-Logging.Via ConduitNov 22 2014, 12:45 AM
bzimport set Reference to bz42246.
Isarra created this task.Via LegacyNov 18 2012, 7:39 PM
Bawolff added a comment.Via ConduitJan 4 2013, 6:04 PM

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).

Bawolff added a comment.Via ConduitJan 4 2013, 6:20 PM

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.

Nemo_bis added a comment.Via ConduitJan 4 2013, 7:19 PM

(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?

Bawolff added a comment.Via ConduitJan 4 2013, 7:26 PM

(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.

Nemo_bis added a comment.Via ConduitJan 4 2013, 7:30 PM

(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.

Bawolff added a comment.Via ConduitJan 4 2013, 7:30 PM

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...

Nemo_bis added a comment.Via ConduitJan 4 2013, 7:36 PM

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

Nemo_bis added a comment.Via ConduitJan 6 2013, 11:04 AM

(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.

Bawolff added a comment.Via ConduitJan 8 2013, 8:59 PM

(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

gerritbot added a comment.Via ConduitSep 12 2013, 7:04 PM

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

Nemo_bis added subscribers: brion, Unknown Object (MLST), bzimport.Via WebMay 14 2015, 7:29 AM

Add Comment