Last modified: 2014-09-30 01:23:12 UTC
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.
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
