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.

In T44246#1887892, @Cenarium wrote:

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.

In T44246#1888256, @Nemo_bis wrote:

In T44246#1887892, @Cenarium wrote:

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

In T44246#3684909, @gerritbot wrote:

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

Shouldn't this be resolved?

In T44246#4281421, @MGChecker wrote:

Shouldn't this be resolved?

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/258413/ by @Cenarium is still open and needs rebasing.

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