Last modified: 2007-01-17 21:20:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8621 - Log revisions marked as patrolled
Log revisions marked as patrolled
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: High enhancement with 5 votes (vote)
: ---
Assigned To: Rob Church
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-13 10:45 UTC by Yorian
Modified: 2007-01-17 21:20 UTC (History)
1 user (show)

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


Attachments
Patch to log who marked revisions as patrolled (3.33 KB, patch)
2007-01-15 16:17 UTC, Jelte (WebBoy)
Details
Complete patch to log who marked revisions as patrolled (13.46 KB, patch)
2007-01-16 14:40 UTC, Jelte (WebBoy)
Details

Description Yorian 2007-01-13 10:45:34 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 :)
Comment 1 Venullian 2007-01-13 13:32:21 UTC
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)
Comment 2 Christoffel K 2007-01-14 11:05:56 UTC
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.
Comment 3 jeroenvrp 2007-01-14 12:24:45 UTC
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!
Comment 4 Yorian 2007-01-15 10:54:32 UTC
It also can be done by just adding a new log type. It looks really easy to code.
Comment 5 Rob Church 2007-01-15 12:05:50 UTC
(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.
Comment 6 Yorian 2007-01-15 13:01:50 UTC
(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. 
Comment 7 Jelte (WebBoy) 2007-01-15 16:17:09 UTC
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.
Comment 8 Rob Church 2007-01-15 16:24:17 UTC
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.
Comment 9 jeroenvrp 2007-01-15 16:28:17 UTC
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. 
Comment 10 Rob Church 2007-01-15 16:30:29 UTC
Sure, we'll commit a patch that doesn't fix the problem.
Comment 11 Yorian 2007-01-15 16:32:44 UTC
(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.

Comment 12 Connel MacKenzie 2007-01-15 23:25:37 UTC
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.
Comment 13 Yorian 2007-01-16 08:24:06 UTC
(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.
Comment 14 Yorian 2007-01-16 08:24:58 UTC
(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?
Comment 15 Brion Vibber 2007-01-16 08:32:39 UTC
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.)
Comment 16 Connel MacKenzie 2007-01-16 08:39:03 UTC
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.
Comment 17 Yorian 2007-01-16 08:41:45 UTC
(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.
Comment 18 Jelte (WebBoy) 2007-01-16 14:40:05 UTC
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.
Comment 19 Rob Church 2007-01-16 14:45:43 UTC
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.
Comment 20 Jelte (WebBoy) 2007-01-16 15:18:00 UTC
(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?
Comment 21 Rob Church 2007-01-16 17:06:34 UTC
Fixed in r19341.
Comment 22 Yorian 2007-01-16 17:19:04 UTC
(In reply to comment #21)
> Fixed in r19341.


Thanks!
Comment 23 jeroenvrp 2007-01-16 17:47:38 UTC
Great news! Thank you Rob and WebBoy!
Comment 24 Venullian 2007-01-16 18:26:20 UTC
Thank you very much! This is great news!
Comment 25 Connel MacKenzie 2007-01-17 21:20:59 UTC
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?

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


Navigation
Links