Page MenuHomePhabricator

rebuildrecentchanges should not generate entries for rc-suppressing log events (e.g. patrol)
Closed, ResolvedPublic

Description

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


See Also:
T49789: rebuildall.php maintenance script adds RC log entries (e.g. "Patrol Log") that would not normally be there

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:37 PM
bzimport set Reference to bz18364.
bzimport added a subscriber: Unknown Object (MLST).

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.

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.

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.

FT2.wiki wrote:

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?

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.

mike.lifeguard+bugs wrote:

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

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.

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

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

mike.lifeguard+bugs wrote:

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

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

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.

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.

ed.wunch wrote:

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

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.

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

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

GeoffreyT2000 added a subscriber: GeoffreyT2000.

It should use array_merge for $wgLogRestrictions and $wgFilterLogTypes. I'll upload a Gerrit patch to fix this bug.

Change 368336 had a related patch set uploaded (by GeoffreyT2000; owner: GeoffreyT2000):
[mediawiki/core@master] Don't generate RC entries for filterable log types

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

Change 368337 had a related patch set uploaded (by GeoffreyT2000; owner: GeoffreyT2000):
[mediawiki/core@REL1_29] Don't generate RC entries for filterable log types

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

Change 368337 abandoned by GeoffreyT2000:
Don't generate RC entries for filterable log types

Reason:
Oops, I should have waited until Id18364599b44d16f867f1042e1dc7e8f51b1b369 gets merged.

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

Change 368336 merged by jenkins-bot:
[mediawiki/core@master] Don't generate RC entries for filterable log types

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

matej_suchanek removed a project: Patch-For-Review.
matej_suchanek updated the task description. (Show Details)