Page MenuHomePhabricator

IRC recent changes feed does not list patrol log entries
Closed, ResolvedPublic

Description

Author: matthew.britton

Description:
The IRC recent changes feed provides log entries for most types of action. However, it does not do so for page patrolling. Clients wishing to know when pages are patrolled have to periodically query the API instead; including the information in the IRC recent changes feed would be more efficient.


Version: unspecified
Severity: normal

Details

Reference
bz16604

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 10:24 PM
bzimport set Reference to bz16604.

Listing patrol actions would, IMHO, clutter the output completely, since on some wikis, most active users (including bots) have autopatrol rights (with every edit, there'd come a patrol action). OTOH, for completeness' sake, it would be logical to output that as well...

If the edit was autopatrolled with an edit, it could be noted on the same edit list, eg. adding a ! along the NMB flags. OTOH I'm not sure how to list 'just patrolling' being coherent with that output.

matthew.britton wrote:

(In reply to comment #1)

Listing patrol actions would, IMHO, clutter the output completely, since on
some wikis, most active users (including bots) have autopatrol rights (with
every edit, there'd come a patrol action). OTOH, for completeness' sake, it
would be logical to output that as well...

Ah, so it would. I was thinking only of new page patrolling, silly me.

In that case I think Platonides' idea is better; add a one-character flag to autopatrolled edits and then list any manual patrols separately using the same format as other log entries.

We are running r45795 and I got after every edit is this:

02:48 < rc2010> [[MediaWiki:Sidebar]] http://www.wikimania2010.pl/w/index.php?diff=1173&oldid=1168&rcid=1229 * Saper * (+35) +wracają wydarzenia
02:48 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *

Saper (myself) is a bureaucrat and sysop (with patrol and autopatrol rights).

Every change gets listed this way twice, should autopatrolled changes be skipped?

We run with patrolling defaults, i.e.:

$wgUseRCPatrol = true;
$wgUseNPPatrol = true;

bretthillebrand wrote:

I too am having this issue with my RC bot, it lists every change being patrolled. (Both auto and manual)

For the time being I have disabled patrolling

Can someone fix or revert this. ~~~~

Entries should be gone in r45863

Yes, now it looks much better, thanks!

Well, the only problem is that manual patrol is not very informative:

22:09 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:09 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:09 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:10 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:10 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:11 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:12 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:15 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *
22:15 < rc2010> [[Specjalna:Log/patrol]] patrol * Saper *

Some indication what got patrolled might have been useful.

Yes, we still get autopatrolled edits fed into the RC stream.

I don't know if this is related to this but with r45879 we also have "Mark as patrolled" link present also on changes
of autopatrol users, see

http://www.wikimania2010.pl/w/index.php?diff=1344&oldid=1340&rcid=1714&uselang=en

The use who did this edit is a bureaucrat with autopatrol right.

However, recent changes do not show exclamation mark for this change (as they do for the non-patrolled changes).

Installed r45956. Indeed, now autopatrolled edits have no "Mark as patrolled" link.
However, I still get autopatrolled changes delivered via UDP interface and the message is not very informative:

This is the python repr() of the string I get:

'\x0314[[\x0307Specjalna:Log/patrol\x0314]]\x034 patrol\x0310 \x0302\x03 \x035*\x03 \x0303TestTest\x03 \x035*\x03 \x0310\x03'

where "TestTest" is the username.

Due to a typo, fixed in r45961

matthew.britton wrote:

(In reply to comment #15)

Due to a typo, fixed in r45961

Yep, that works fine now.

So the only remaining issue is that from comment #11. The patrol lines are all of the form:

14[[ 07Special:Log/patrol 14]] 4 patrol 10  02   5*   03Gurch   5*    10

which says that something was patrolled, and by whom, but not *what was actually patrolled*. This makes it rather useless. The output needs to include the page name and either the revision id or the rcid (for new page patrolling, only the page name is strictly necessary, but it's probably easier to be consistent).

I though the IRC line function added the title for logs...seems to depend on $actionComment

OK, fixed in r45974. PatrolLog had it's own inconsistent code for the action text.

  1. Issue #11 gone, so we have now a description of the patrol action
  2. Autopatrolled edits do not show up in the log
  3. However, I still get the "Mark this change as patrolled" for the sysop and bureaucrat edits, that should be autopatrolled anyway (there is no "!" in the RecentChanges, and clicking "Mark this change as patrolled" does not generate a log entry).

matthew.britton wrote:

(In reply to comment #20)

I still get the "Mark this change as patrolled" for the sysop and
bureaucrat edits, that should be autopatrolled anyway (there is no "!" in the
RecentChanges, and clicking "Mark this change as patrolled" does not generate a
log entry).

I believe that this problem is related to the inclusion of the 'rcid' parameter in URLs and thus unrelated to the addition of patrol log entries. At any rate, a separate issue - bug 17104 - seems to have been filed for it; you may wish to comment there.

spacebirdy wrote:

Thanks to this showing of autocreations and certain logs the rc-feed has become totally unreadable and broken many bots of the SWMT...

matthew.britton wrote:

(In reply to comment #22)

Thanks to this showing of autocreations and certain logs the rc-feed has become
totally unreadable and broken many bots of the SWMT...

Each log entry is a separate line... assuming the bots are using some sort of line-by-line pattern-matching and discarding unrecognized lines, I don't quite see how this can have broken anything. At any rate, autocreations being shown in the logs is something completely unrelated to this issue report.

The changes made as a result of this issue are essential for external programs to efficiently interact with MediaWiki wikis where patrolling is used. This in turn is essential to many aspects of some large Wikimedia wikis, monitoring for vandalism and other abuse being the main one.

mike.lifeguard+bugs wrote:

(In reply to comment #23)

(In reply to comment #22)

Thanks to this showing of autocreations and certain logs the rc-feed has become
totally unreadable and broken many bots of the SWMT...

Each log entry is a separate line... assuming the bots are using some sort of
line-by-line pattern-matching and discarding unrecognized lines, I don't quite
see how this can have broken anything. At any rate, autocreations being shown
in the logs is something completely unrelated to this issue report.

The changes made as a result of this issue are essential for external programs
to efficiently interact with MediaWiki wikis where patrolling is used. This in
turn is essential to many aspects of some large Wikimedia wikis, monitoring for
vandalism and other abuse being the main one.

The automatic account creations are hidden in RC for the same reason they should be hidden in the RC feed. They're an artefact of the Single User Login system and flood RC, so they're unnecessary to list (and make the RC feed less usable) - doubly so since unifications are broadcasted in a dedicated feed.

matthew.britton wrote:

(In reply to comment #24)

The automatic account creations are hidden in RC for the same reason they
should be hidden in the RC feed. They're an artefact of the Single User Login
system and flood RC, so they're unnecessary to list (and make the RC feed less
usable) - doubly so since unifications are broadcasted in a dedicated feed.

Fair enough. Since that has nothing to do with patrol log, filed as bug 17220.