Last modified: 2013-09-19 13:16:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20364, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18364 - rebuildrecentchanges should not generate entries for rc-suppressing log events (e.g. patrol)
rebuildrecentchanges should not generate entries for rc-suppressing log event...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Maintenance scripts (Other open bugs)
1.16.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-06 00:14 UTC by Dan Jacobson
Modified: 2013-09-19 13:16 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2009-04-06 00:14:32 UTC
Problem: each new user signing up creates an entry in recentchanges.

This might be hardly noticeable on larger wikis, but on smaller wikis
this quickly becomes the main content of recentchanges, which thus
becomes useless to monitor anymore due to distraction.

In fact it might invite vandalism, "let's create fun names so everybody
can see."

We want them logged, but not also in recentchanges.

Solution: an simple array in DefaultSettings.php, containing what events that
should be added to recentchanges. No need to install extensions.

New user creation would still be 'on' in it by default, but at least the
administrator could now easily turn it off if desired... along with any
other events he no longer wished to show up in recentchanges!

This array could also be used in maintenance/rebuildrecentchanges.php
eliminating the need for the hard-to-maintain list currently there.

Hmmm, it seems this array be an initially empty list of event types to exclude.

Assign this bug to me if you think it is worthwhile, and I'll come up
with a patch, if nobody better skilled would rather.

One worry is "hey, your wiki is broken, new users don't show up".
Perhaps at the bottom of recentchanges there could be
"Only ..., ..., ..., events are listed. See the [[Special:Log]] for
other information".
Comment 1 Dan Jacobson 2009-04-06 00:45:29 UTC
Indeed, http://techblog.wikimedia.org/2009/04/planning-to-tighten-torblock-restrictions/ mentions
"a rash of abuse ...in the form of account creations with abusive names".

There would be little thrill if they didn't show up in recentchanges.
Comment 2 Roan Kattouw 2009-04-07 16:36:14 UTC
Note that this is already done for patrol log entries, so there is precedent (although 'patrol' is just hardcoded right now IIRC). There's also a boolean parameter to the LogPage constructor (IIRC) that suppresses creation of an RC entry.
Comment 3 Platonides 2009-04-07 22:51:46 UTC
The solution should be to add an option for RecentChanges to hide account creations, hide blocks...
Hardcoding 'things that are distracting for small wikis' to hide them is too subjective and won't scale.
Comment 4 FT2 2009-04-07 22:59:20 UTC
What feeds and vandalism/activity monitoring bots and software would be broken or impaired by this, due to relying on RC feed to spot new usernames etc?
Comment 5 Dan Jacobson 2009-04-07 23:53:12 UTC
Nothing need be broken, just make the current behavior the default in
the new array there in DefaultSettings.php.

We small wiki owners would now have a tool to move the focus of our
wikis back to content, not personal networking, like it used to be
before recentchanges suddenly started advertising new account creation
(it seems, or my wiki got popular?)

With this array, no more hardwiring need be done in all the various
places that access the recentchanges table, including
rebuildrecentchanges.php.

It's darn frightening to see those new accounts pop up one after
another, with the only non-hack solutions available being 1. Turn off
new account creation. 2. Remove recent changes from the sidebar.
Comment 6 Mike.lifeguard 2009-04-08 19:31:12 UTC
(In reply to comment #4)
> What feeds and vandalism/activity monitoring bots and software would be broken
> or impaired by this, due to relying on RC feed to spot new usernames etc?
> 

FWIW, SULWatcher relies on CentralAuth's IRC feed, not RecentChanges, so it'd be unaffected.

(In reply to comment #1)
> Indeed,
> http://techblog.wikimedia.org/2009/04/planning-to-tighten-torblock-restrictions/
> mentions
> "a rash of abuse ...in the form of account creations with abusive names".
> 
> There would be little thrill if they didn't show up in recentchanges.
> 

If we're talking about the same thing, accounts are generally hidden within a minute - there would be no significant change in the "trill level". That said, there are other vandals, and it's worth considering for other reasons as well.
Comment 7 Dan Jacobson 2009-04-08 21:30:55 UTC
Well imagine a wiki where no pages usually change much more than a
bimonthly meeting announcement.

There recentchanges just fill up with the kiddies to the point where you
can forget about finding the announcement, nor anybody coming to the
meetings.

No need to clamp off new accounts. Just make them not have advertising
value, just as they don't on most BBSs, forums, UNIX, you name it.
Comment 8 Chad H. 2009-04-08 21:33:46 UTC
(In reply to comment #7)
> No need to clamp off new accounts. Just make them not have advertising
> value, just as they don't on most BBSs, forums, UNIX, you name it.
> 

Call me when we're a BBS, forum, or UNIX.

Now, a way to hide it from view might be useful yes.
Comment 9 Dan Jacobson 2009-04-12 22:11:02 UTC
Some findings when looking for a workaround to showing new account creation:

$wgNewUserLog=false will stop new entries from being added, but won't
clean up the present ones. And one doesn't want to disable logging of
new users just to keep them out of RC. So one turns to
$wgLogRestrictions['newusers']='editinterface' just to keep them out of
RC, but this does not clean up the present ones, nor does
rebuildrecentchanges.php (Bug #18441) help. Probably must resort to a hook...
Comment 10 Mike.lifeguard 2009-04-13 03:49:48 UTC
(In reply to comment #2)
> Note that this is already done for patrol log entries, so there is precedent
> (although 'patrol' is just hardcoded right now IIRC). There's also a boolean
> parameter to the LogPage constructor (IIRC) that suppresses creation of an RC
> entry.
> 

I don't think that it is hardcoded, though I can't find the commit presently. IIRC, Aaron added that, so I've CCed him.
Comment 11 Dan Jacobson 2009-04-14 05:35:09 UTC
By the way, import a new page with Special:Import,
In Recentchanges one only sees
 (Import log); 12:06 . . WikiSysop (Talk | contribs | block) imported UUU by file upload (1個修訂)
After using rebuildrecentchanges.php one sees two entries,
 (Import log); 12:06 . . WikiSysop (Talk | contribs | block) imported UUU by file upload (1個修訂)
 (diff) (hist) . . m UUU‎; 12:06 . . (0) . . WikiSysop (Talk | contribs | block) (1個修訂) [rollback]
Now set $wgLogRestrictions['import']='editinterface'; and run
rebuildrecentchanges.php again.
Now one only sees
 (diff) (hist) . . m UUU‎; 12:06 . . (0) . . WikiSysop (Talk | contribs | block) (1個修訂) [rollback]
There is too many combinations to test. My head is spinning. All I can
say is that regular and rebuilding RC should go thru the same function...
Comment 12 Dan Jacobson 2009-04-26 06:02:41 UTC
Today at r49455, with $wgLogRestrictions['import']='editinterface'; I
imported some revisions to some existing pages.
Nothing changed at all in RecentChanges.
So I ran rebuildrecentchanges.php. I got the familiar double entries:
each with one for the revision, and one minor one for the import.
As this is tolerable (the user can exclude seeing minor edits) I'll no
longer use $wgLogRestrictions['import']='editinterface'; as it makes
RecentChanges act differently than rebuildrecentchanges (BUG), and wipes out
both lines in RecentChanges until one runs rebuildrecentchanges.
Comment 13 Dan Jacobson 2009-05-26 13:46:43 UTC
OK, one can get grudgingly by with e.g., $wgLogRestrictions['newusers']='editinterface' to keep things also out of recentchanges.
however, rebuildrecentchanges still needs to act the same as plain recentchanges.
Hence I'm changing the Summary.
Comment 14 Ed 2011-10-31 21:43:29 UTC
This issue also affects any extensions which build on the LogPage class.  For example, http://www.mediawiki.org/wiki/Extension:UserLoginLog instantiates a child of LogPage with parameters ( * , false ).  It succeeds in avoiding the recentchanges table when it initially adds items to the logging table.  After you run rebuildrecentchanges, all those items are added to the log.

In this instance, $wgLogRestrictions['userlogin']='read' would I guess work just as well.

In terms of a fix, I'm having trouble figuring out how to fix this without changing database table layouts (i.e. adding a true/false field for rc/no-rc).

It might also be possible if you cached new log entries to be added to RC and then have rebuildRC read the cache into the DB.  I have no idea how you would cache that information without, again, database rewrite.

-Ed
Comment 15 Krinkle 2012-12-01 11:41:18 UTC
Rephrasing bug summary. Especially annoying for patrol edits.

I just rebuilt recentchanges for a wiki I maintain and it added 1000s of patrol events to Special:RecentChanges that don't belong there. Especially silly because patrol is to work and reduce unpatrolled recent changes, doesn't make sene that such an event results in an entry being added.
Comment 16 Krinkle 2012-12-01 11:42:13 UTC
Even autopatrol events are included, which means every single edit done by a user who has the autopatrol right will get 2 entries in recentchanges after this script is ran (one for the edit, one for the autopatrol).
Comment 17 Brad Will (tmbw.net) 2013-04-29 12:56:53 UTC
It looks like this is your culprit:

<code>
// Some logs don't go in RC. This should check for that
$basicRCLogs = array_diff( $wgLogTypes, array_keys( $wgLogRestrictions ) );
</code>

And, here's the definition of $wgLogRestrictions from DefaultSettings.php:
$wgLogRestrictions = array( 'suppress' => 'suppressionlog' );

Maybe the code should be using this array instead?
$wgFilterLogTypes = array( 'patrol' => true );

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links