Last modified: 2014-11-18 18:07:27 UTC
When a page is first edited by a normal user, and then by a bot, the page isn't showing on the watchlist if you have 'Hide bot edits' enabled. The same is true for 'Hide my edits' and 'Hide minor edits'. The SQL causing this bug is "rc_this_oldid=page_latest" on line 261 of includes/SpecialWatchlist.php. This bug only occurs when 'Expand watchlist to show all applicable changes' is turned off.
This is how the watchlist works; the default is to show one edit per page, and if, for instance, a bot made the edit, and bots are being filtered, then the edit won't show. I suspect that retrieving the next edit could prove too expensive.
*** Bug 11596 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > This is how the watchlist works; the default is to show one edit per page, and > if, for instance, a bot made the edit, and bots are being filtered, then the > edit won't show. > > I suspect that retrieving the next edit could prove too expensive. > Can't this just be done by something like: SELECT whatever,you,want FROM revision WHERE rev_minor_edit=0 ORDER BY rev_timestamp LIMIT 1
(In reply to comment #1) > This is how the watchlist works; the default is to show one edit per page, and > if, for instance, a bot made the edit, and bots are being filtered, then the > edit won't show. > > I suspect that retrieving the next edit could prove too expensive. > From a user point of view, this is definitely not the expected behaviour.
The easiest thing might be to just always do the expanded watchlist lookup (grabbing all edits during the period, rather than only latest)... If it's necessary to keep the last-change-only view, we could just discard the extra rows on display. :P
Based on some testing on the toolserver, it seems that appending the rc_timestamp column to the rc_namespace_title index would allow MySQL to efficiently optimize a query for "the RC entry with maximum timestamp satisfying these criteria for each of these titles" using either of the two methods recommended at http://dev.mysql.com/doc/refman/5.0/en/example-maximum-column-group-row.html . This would allow a simple and efficient fix for this bug.
With the index change suggested above, the most efficient query (at least based on my toolserver testing) appears to be something like: SELECT $columns FROM recentchanges, (SELECT rc_namespace AS max_namespace, rc_title AS max_title, MAX(rc_timestamp) AS max_timestamp FROM recentchanges, watchlist WHERE rc_namespace = wl_namespace AND rc_title = wl_title AND ($conditions) GROUP BY rc_namespace, rc_title) AS rcmax WHERE rc_namespace = max_namespace AND rc_title = max_title AND rc_timestamp = max_timestamp ORDER BY rc_timestamp DESC; (Note that this can return multiple rows per page if two changes to the same page occur within one second. (Yes, this does occasionally happen on busy wikis.) If rc_id can be relied on to be strictly ascending, it could be substituted for rc_timestamp above, but then the proposed index would have to be modified accordingly.)
...in fact, it seems that, with MySQL and InnoDB, the current indices would be sufficient for the rc_id based approach (since InnoDB essentially appends the primary key to every index). Probably not so good for PostgreSQL, though. Still, the following works and runs in reasonable time even on the current indices: SELECT recentchanges.* FROM recentchanges, (SELECT MAX(rc_id) AS max_id FROM watchlist, recentchanges WHERE rc_user = 398996 AND rc_namespace = wl_namespace AND rc_title = wl_title AND rc_bot = 0 GROUP BY rc_namespace, rc_title) AS rcmax WHERE rc_id = max_id ORDER BY rc_id DESC;
Changing component to "Watchlist"
*** Bug 23309 has been marked as a duplicate of this bug. ***
Any progress on this ? Ilmari Karonen's query works according to him. Perhaps put this to more testing and/or implementation.
This is a problem: editors are watching bot edits to ensure that non-bot edits aren't missed, then suffering when their watchlist lights up like the proverbial Christmas Armadillo.
*** Bug 8965 has been marked as a duplicate of this bug. ***
Reported 5 years ago and still NEW? It seems everybody understands the problem. Why not fix it?
*** Bug 34163 has been marked as a duplicate of this bug. ***
This BUG remains one of the most annoying things in the software for active editors with large watchlists. The problem is getting worse and worse as more bots are appearing. The current behavior is contrary to the documentation ("Hide bot edits from the watchlist" is not what actually happens) and makes monitoring of large numbers of articles for human-created problems a real chore.
(In reply to comment #16) > The problem is getting worse and worse as more bots are appearing. Please note that this only applies to bot edits and minor edits. It does not apply to own edits. If I hide my own edits I want to hide all previous edits too. A good example is a talk page. If a user adds a question to a talk page I can see this in my watchlist. I edit the talk page and add my answer. It would not make any sense to hide my edit but not to hide the previous edit too. It would look like I did not answered the question. This would be very confusing. Therefor this bug only applies to bot edits and minor edits and should be renamed, please.
*** Bug 54154 has been marked as a duplicate of this bug. ***
*** Bug 57797 has been marked as a duplicate of this bug. ***
It would make better sense if preferences "Ignored bots", otherwise you can miss recent changes. Likewise it should be "ignore minor edits".
*** Bug 23288 has been marked as a duplicate of this bug. ***
(In reply to TMg from comment #17) > (In reply to comment #16) > > The problem is getting worse and worse as more bots are appearing. > > Please note that this only applies to bot edits and minor edits. It does not > apply to own edits. If I hide my own edits I want to hide all previous edits > too. > > A good example is a talk page. If a user adds a question to a talk page I > can see this in my watchlist. I edit the talk page and add my answer. It > would not make any sense to hide my edit but not to hide the previous edit > too. It would look like I did not answered the question. This would be very > confusing. > > Therefor this bug only applies to bot edits and minor edits and should be > renamed, please. At least a confusing entry could be resolved with a mouse-click. A confusing lack of an entry causes greater pain.
Caveat emptor: the alert "will also hide previous non-bot edits" must be appended to the text "Hide bot edits from the watchlist" -- otherwise it's false advertisement! (I'm referring to page Special:Preferences#mw-prefsection-watchlist) There is absolutely no technical excuse for not implementing this immediately, please!
(In reply to fgnievinski from comment #23) > Caveat emptor: the alert "will also hide previous non-bot edits" must be > appended to the text "Hide bot edits from the watchlist" -- otherwise it's > false advertisement! (I'm referring to page > Special:Preferences#mw-prefsection-watchlist) There is absolutely no > technical excuse for not implementing this immediately, please! better: "may also hide previous non-bot edits".
Throwing my voice into the din, in case anyone is listening 7+ years on... Someone please make it so that when bot edits are hidden, the most recent non-bot edit remains visible. No one would suffer, many would be happier.
