Last modified: 2013-07-01 15:21:17 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 T27799, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25799 - Use separate log_action for patrol action of autopatrolled edits
Use separate log_action for patrol action of autopatrolled edits
Status: NEW
Product: MediaWiki
Classification: Unclassified
Patrolling (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: Future release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 28412
  Show dependency treegraph
 
Reported: 2010-11-05 15:42 UTC by Krinkle
Modified: 2013-07-01 15:21 UTC (History)
8 users (show)

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


Attachments

Description Krinkle 2010-11-05 15:42:50 UTC
Currenltly I see no way to see sombody's patrollog without his or her own 'edits' in between (not really edits but autpatrols).
As far as I can see these are stored in a different way and can be identified as such.


Example: http://commons.wikimedia.org/w/index.php?title=Special%3ALog&type=patrol
Some have (automatic) behind them.

A userscript that executes the following exists:
<code>
jQuery(".mw-logline-patrol:contains('automatic')").hide();
</code>
But if the user page 50 edits since the last patrol the list will be empty (or 500 of that matter).

So way to filter these (wether or not by storing the seperatly entirely - or perhaps not store autopatrol in the database at all ?) enabling to see the actual patrol log, that would be handy.

-
Krinkle
Comment 1 Bawolff (Brian Wolff) 2010-11-06 19:47:03 UTC
Bug 22738 would provide (provides?) a method to do this in the api.
Comment 2 Krinkle 2010-11-12 12:35:36 UTC
not quite, as autopatrols and patrols are both saved with the same log_type and log_action.
I haven't traced yet how MediaWiki's Special:Log/patrol extracts the information to append or not append "(automatic)" to the log entry, but in my toolserver tools I do this by digging through log_params *after* the query in a foreach loop since I noticed in the second or third line of that string is a '1' that indicates whether it's autopatrolled or not.

Asuming MediaWiki does it the same way on the log page, this definitely needs attention.
I think making it a seperate log_action would make sense (just like log_type 'upload' has log_action 'upload' and 'overwrite', log_type 'patrol' could have log_action 'patrol' and 'autopatrol').
Comment 3 Bawolff (Brian Wolff) 2010-11-12 19:01:26 UTC
> I haven't traced yet how MediaWiki's Special:Log/patrol extracts the
> information to append or not append "(automatic)" to the log entry, but in my
> toolserver tools I do this by digging through log_params *after* the query in a
> foreach loop since I noticed in the second or third line of that string is a
> '1' that indicates whether it's autopatrolled or not.

As it stands the first parameter is the current revision id, the second parameter is the revision id of the previous revision, and the third parameter is if its Automatic or not.

The code for displaying this mostly happens at PatrolLog::makeActionText in PatrolLog.php. You're right that the processing takes place after the query.
Comment 4 Krinkle 2010-11-12 21:30:51 UTC
I remember from last september I did a query on the toolserver to get some statistics for our edit-patrol team. The results are here:
http://commons.wikimedia.org/wiki/CT:CVU
Although in my tools, like I said in comment 2, I do it post-query, I know for sure that in this particular table I did it all within the query (excluding autopatrols), I'll see if I can digg up how I did that.
Comment 5 Bawolff (Brian Wolff) 2010-11-12 21:42:16 UTC
Well its entirely possible to do something like that in sql, I'm very doubtful it can be done efficiently, which makes it a moot point. (Although then again I don't think querying by log_action, which was proposed earlier, is efficient either, or at least not currently).
Comment 6 Krinkle 2010-11-12 21:51:27 UTC
Well, in the API it is already possible to filter by log_action. So if autopatrols would be recorded as such, it's possible to use the API to only get 'real' patrols.

In the front-end there's only a way to filter by log_type, but that's fine I don't think log_action is really something that would be used from a front-end.

It may be interesting in general, to improve that API-functionality, to add an INDEX on log_action though...

But aside from the API-functionality. The main point is that different actions should be recorded as different actions, and for Patrol this is not the case. (overwrite and upload are differrent log_action's)
Comment 7 Krinkle 2010-11-12 21:56:07 UTC
I found the query by the way:

// Get patrol statistics
$dbQuery = "
SELECT

	count(*) AS counter,
	log_action,
	user_name,
	user_registration,
	user_editcount

FROM logging log
 
JOIN user us
  ON log.log_user = us.user_id
 
WHERE log.log_type = 'patrol'
AND log.log_action = 'patrol'
AND log.log_params LIKE '%\n0' /* <-- this line */
GROUP BY log.log_user
  
ORDER BY counter DESC
LIMIT 50;";

So yeah, that's everything but effecient. The query run took little over 5-6 minutes.
Comment 8 Bawolff (Brian Wolff) 2010-11-13 22:39:15 UTC
btw, this is related to Bug 18954 .
Comment 9 Krinkle 2011-04-11 22:01:02 UTC
Summarized;

Right now vandal-fighters that patrol edits and/or new pages have both their own edits and the edits that they patrolled under the same log_type and log_action.

Although the front-end view of this on-wiki would be bug 18954, I'm going to rephrase this bug (bug 25799) to implement the actual log action, which must be done first.

I'm hoping to implement the autopatrol log_action later this week / early next week.
Comment 10 Krinkle 2012-02-25 17:11:32 UTC
I've had no progress on this due to the fact that I'm pretty much stuck on the migration path (if any).

hard part:

Need to convert old "automatic" boolean indicator on the 3rd line of log_params to a log_action

easier part:

Change the patrol action saving to set a different log_action if patrol is done automatically (instead of setting the 3d line in unindexable log_params).
Comment 11 Rainer Rillke @commons.wikimedia 2012-03-20 12:03:22 UTC
Somehow even the "(automatic)" disappeared in the UI.
Comment 12 Nemo 2012-07-25 07:44:21 UTC
(In reply to comment #11)
> Somehow even the "(automatic)" disappeared in the UI.

Works for me.
Comment 13 Rainer Rillke @commons.wikimedia 2012-07-26 11:04:13 UTC
(In reply to comment #12)
Confirmed. The message seems to have been rephrased: https://translatewiki.net/w/i.php?title=MediaWiki:Logentry-patrol-patrol-auto/de&action=history
Comment 14 Mark A. Hershberger 2012-09-28 19:05:15 UTC
pushing to future since release is imminent.
Comment 15 Krinkle 2013-05-25 13:53:40 UTC
See bug 17237 for a solution.
Comment 16 Nemo 2013-07-01 15:21:17 UTC
(In reply to comment #7)
> AND log.log_params LIKE '%\n0' /* <-- this line */

I've been using this for older log entries, but it seems something changed recently. On en.wiki (TS):

mysql> SELECT max(log_timestamp)
    -> FROM logging log
    -> WHERE log.log_type = 'patrol'
    -> AND log.log_action = 'patrol'
    -> AND log.log_params LIKE '%\n0' ; /* not autopatrolled */
+--------------------+
| max(log_timestamp) |
+--------------------+
| 20120229230745     |
+--------------------+
1 row in set (5 min 1.28 sec)

Which is the day 1.19 was deployed... :S

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


Navigation
Links