Last modified: 2013-07-01 15:21:17 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
Bug 22738 would provide (provides?) a method to do this in the api.
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').
> 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.
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.
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).
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)
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.
btw, this is related to Bug 18954 .
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.
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).
Somehow even the "(automatic)" disappeared in the UI.
(In reply to comment #11) > Somehow even the "(automatic)" disappeared in the UI. Works for me.
(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
pushing to future since release is imminent.
See bug 17237 for a solution.
(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
