Last modified: 2007-01-17 21:20:59 UTC
I propose to add a function that will keep a log of all the people who clicked on "mark as patrolled", so you get a list of who marked which change. This would be really helpful, on nl.wikipedia sometimes changes are marked as patrolled and not reverted while the change is incorrect. We would like to find out who do this. It would be pretty easy to implent, though a new table has to be added (I don't know whether that is a big obstacle or not). Apart from that there just has to be a little script when action=markpatrolled that will write the rcid, oldid, diffid and the title of the article (maybe there is a more efficient way) and the name of the person that marked as patrolled. The sooner this function is added, the better :)
I would like to support this request. On nl wikipedia we are using this "marked as patrol" function daily to control vandalism as good as we can. We would like to know whether recent problems are because of mistakes of regular users (then we can point them in the right direction) or whether we have vandals walking around marking as patrolled. So if this feature request could be done, we would be very grateful. Venullian (from nl and en wikipedia, amongst others)
I strongly support this proposal. The possibility to mark an edit as patrolled, helpt a lot at Dutch Wikipedia in the fight against vandalism, but now there seems to be a vandal, marking vandalism as patrolled all the time.
This is a high priority. There are many great things added to MediaWiki, but they are not high priority. Because this issue is related to the Dutch language Wikipedia and not to the English language Wikipedia, doesn't mean this isn't a high priority. It is!
It also can be done by just adding a new log type. It looks really easy to code.
(In reply to comment #4) > It also can be done by just adding a new log type. It looks really easy to code. I look forward to reviewing your patch, then.
(In reply to comment #5) > (In reply to comment #4) > > It also can be done by just adding a new log type. It looks really easy to code. > > I look forward to reviewing your patch, then. I would love to do that, unfortanely, my knowledge of PHP isn't great, I would probably only offer rubbish.
Created attachment 3074 [details] Patch to log who marked revisions as patrolled This patch changes Article.php and RecentChange.php to log who marked a revision as patrolled in two new fields in the recentchanges table, rc_patrolled_by and rc_patrolled_by_text. This patch DOES NOT include an updater to execute: ALTER TABLE `recentchanges` ADD `rc_patrolled_by` INT( 10 ) UNSIGNED NULL AFTER `rc_patrolled` , ADD `rc_patrolled_by_text` VARCHAR( 255 ) CHARACTER SET latin1 COLLATE latin1_bin NULL AFTER `rc_patrolled_by` ; This patch does also not include an update for a special page to show the information, since I don't know an appropriate place and don't have the time to make a new special page. The new information can be retrieved from the Wikimedia Toolserver when needed.
I'd like to point out that logging this information makes no sense unless we store the patrolled status alongside the revisions somehow in the future. This is one of the reasons I'm holding off on implementing this; patrolling probably needs to be rethought in terms of concept and implementation.
Well, I support a rethought of the patrol status, but before this will result in a new implementation, I strongly advise to use WebBoy's patch or a similar solution until the new implementation is ready.
Sure, we'll commit a patch that doesn't fix the problem.
(In reply to comment #8) > patrolling probably > needs to be rethought in terms of concept and implementation. Maybe a funny question to ask, but why should this be rethought? It works fine as it does, except you can't see the patrollers.
The major problem I see with &rcid= is that it does not appear everywhere that a diff (or edited page) does. Also, for any given page/entry/article, there needs to be a "mark all revisions as patrolled" feature...whether or not you are arriving from Special:Recentchanges. Well, especially when not. If I review an entry and clean it up, I should have a button to mark all &rcid='s for it, on that page - and not have to go back to Special:Recentchanges and dig through thousands of edits to find the relevant ones. My Javascript http://en.wiktionary.org/wiki/User:Connel_MacKenzie/patrolled.js whitelisting thing only goes so far, and I have serious doubts that the anon whitelisting is even valid! That is, an anonymous user whitelisting /should/ be for either 24 hours or 30 days, not indefinite. I also need to find time to have it work with "enhanced" recent changes, and add things for marking all "recent" (i.e. the ones that appear on the immediately current Special:Recentchanges page) edits of a user or for a page as patrolled.
(In reply to comment #12) > The major problem I see with &rcid= is that it does not appear everywhere that a > diff (or edited page) does. Also, for any given page/entry/article, there needs > to be a "mark all revisions as patrolled" feature...whether or not you are > arriving from Special:Recentchanges. Well, especially when not. If I review an > entry and clean it up, I should have a button to mark all &rcid='s for it, on > that page - and not have to go back to Special:Recentchanges and dig through > thousands of edits to find the relevant ones. My Javascript > http://en.wiktionary.org/wiki/User:Connel_MacKenzie/patrolled.js whitelisting > thing only goes so far, and I have serious doubts that the anon whitelisting is > even valid! That is, an anonymous user whitelisting /should/ be for either 24 > hours or 30 days, not indefinite. I also need to find time to have it work with > "enhanced" recent changes, and add things for marking all "recent" (i.e. the > ones that appear on the immediately current Special:Recentchanges page) edits of > a user or for a page as patrolled. That are great ideas! But I think we should focus on the short run, we -need- to log the markers and we need it as fast as possible, and as soon as possible. We can do other enhancements later.
(In reply to comment #10) > Sure, we'll commit a patch that doesn't fix the problem. And why doesn't it fix the problem?
We really need more information here on what's being requested. Is the information of who patrolled what public or private? Is anyone allowed to look at the log? Is the public Special:Log interface an appropriate and desirable a place for reviewing this data, or is something else required? eg something like CheckUser? Is the log meant to be permanent? (The patrol tags themselves are not; the data expires along with recentchanges info itself.)
Oh, sorry - I didn't realize you have patrolled edits allowed for *all* registered accounts. On en.wiktionary.org, we only allow sysops to patrol. So you'll just query on the toolserver whenever you need to block an account? Sounds...ineffective. The vandals will just create new accounts immediately.
(In reply to comment #15) > We really need more information here on what's being requested. > > Is the information of who patrolled what public or private? > Is anyone allowed to look at the log? > Is the public Special:Log interface an appropriate and desirable a place for > reviewing this data, or is something else required? > eg something like CheckUser? > Is the log meant to be permanent? (The patrol tags themselves are not; the data > expires along with recentchanges info itself.) Everyone should be able to see it, there doesn't need to be a restriction. I don't care what it looks like, it can be a flat textfile if that's easy to implent ;) But a Special:Log interface would be nice (and easy to implent?). I believe recentchanges data lasts for a month? I think that's quite enough. You see, right now the only thing nl.wiki wants is a solution for the problem and we believe the problem is urgent. So right now we don't care how it looks or how it works, we just want to see who the patrollers are and fix the problem as soon as possible. I understand that Mediawiki doesn't want to have quick fixes, but I think a quick, easy solution for a short while is the best solution right now. After that we can start thinking about a better solution.
Created attachment 3081 [details] Complete patch to log who marked revisions as patrolled This time including an updater, a new special page and dutch translation.
Use the existing logging framework so that all logs are presented in the same location. You can avoid having to update the schema. Your patch contains several deprecated code techniques; the SpecialPage in particular.
(In reply to comment #19) > Use the existing logging framework so that all logs are presented in the same > location. You can avoid having to update the schema. There is no need to keep the data for more then a month. It will just spoil the logging table and Special:Log page since the Dutch Wikipedia has about 1200 edits per day to patrol. > Your patch contains several deprecated code techniques; the SpecialPage in > particular. I just copied most code from ChangesList.php and SpecialRecentchangeslinked.php. Should I wrap the wfSpecialPatrolledChanges() function in a new SpecialPatrolledChanges class? What else is deprecated?
Fixed in r19341.
(In reply to comment #21) > Fixed in r19341. Thanks!
Great news! Thank you Rob and WebBoy!
Thank you very much! This is great news!
After almost 24 hours, I see about 2,900 log entries for en.wiktionary. Is it just me, or does this seem like an excessive amount of logging?
