Last modified: 2014-11-18 18:07:09 UTC
Copy/paste of irc talk (I hope Simetrical and _mary_kate_ wouldn't mind :-) <stemd> question (or feature suggustion/request): <stemd> http://en.wikipedia.org/w/index.php?title=Professor_Balthazar&action=history&hidebots=1 <stemd> there are lot of pages which contain lot of bot action, and few (read one or two) human edits <stemd> as recent changes has filter hidebots=1 <Simetrical> No bot flag in the revision table. * Simetrical looks for bug <stemd> aha <_mary_kate_> join on user_groups <_mary_kate_> ;) <Simetrical> _mary_kate_, different semantics. That would be retroactive. <_mary_kate_> it achieves what the user wants <stemd> Simetrical: (last time I studied db tables of wikipedia was some 2 years ago :-) * Simetrical doesn't see the bug <Simetrical> _mary_kate_, inconsistently with RC. <_mary_kate_> inconsistency in mediawiki oh my whatever next <stemd> select * from revisions where USER != bot :D <stemd> I'll post bug, thanks
Pretty sure this is a duplicate of something.
Maybe you were thinking of bug 11181 ?
Yeah, related issue, although not the same.
*** Bug 16392 has been marked as a duplicate of this bug. ***
Is there a page were bots are a problem?
(In reply to comment #5) > Is there a page were bots are a problem? > Other than the above, of course :)
For small(er) wikis it's quite a problem, see bug 16392: http://als.wikipedia.org/w/index.php?title=%CE%93&curid=7185&action=history There are many page histories that are flooded with single bot edits, making history pages a heavy going sometimes ;-)
As time flies, page histories will become longer (that everybody wants, '''depth''' of the wiki). But if you have 2.000 edits on some page, a few hundred human made edits and rest is a bot edits, you will kill Brion and any other PHP programmer if they soon don't resolve this bug :-), and you for some reason want/have to go deep down the history to find some particular edit. Now is that possible in between 1 minute and 1 hour, when that become 3-4 hours, people will start screaming. So better to do something soon :-) Best wishes for 2009!
Agreed, this is a major issue, not just for small wikis, but for topics that are flooded by bot-happy editors :)
Created attachment 6047 [details] proposed patch This patch may help, i'm not sure about the resulting performance though.
*** This bug has been marked as a duplicate of bug 11181 ***
This is not a duplicate of bug 11181, but it is a blocker for this. Looks like the patch would have issues on pagination, showing less history entries than requested. Also, it is hardcoding the bot group. Assuming you work with the bot group, and there are few bots per wiki, you could get a list of users to filter out, making this hack quite efficient. Perhaps even with a rev_user not IN.
Or you could do a left join. That would be more efficient if there are enough bots. This would have fairly bad worst-case performance in any implementation, I think.
Well, if bug 11181 is fixed, this becomes trivial, same as on RC. That seems like the most sensible way to do it. Without fixing that, you'd also have to hide *all* bot edits, not only edits with the bot flag.
Yes, bug 11181 is the way to do it. Note that even with it, we will want an scrip to retropopulate the value.
Not possible. Not all edits by bots are bot edits. Some bots deliberately do not set the bot flag on their edits, because they don't want to be invisible. We should not make these bots' edits retroactively invisible.
In such case they are unlikely to have bot flag.
(In reply to comment #17) > In such case they are unlikely to have bot flag. The bot flag comes with other privileges, such as higher API query limits. Also, some bots may wish to exercise discretion and mark certain edits as bot edits while leaving others visible.
*** Bug 25099 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > *** Bug 25099 has been marked as a duplicate of this bug. *** Yes, please enable hideBots=1 in history page. Sorry I haven't had the chance to read the whole discussion and technical difficulties. id.wp
*** Bug 20783 has been marked as a duplicate of this bug. ***
+reviewed since the patch received code review in comment 12 and afterwards. Thanks for the patch, Ahmad.
*** Bug 34265 has been marked as a duplicate of this bug. ***
