Last modified: 2014-11-18 18:07:27 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 9790 - Watchlist doesn't show earlier normal edits when hiding bot edits or minor edits
Watchlist doesn't show earlier normal edits when hiding bot edits or minor edits
Status: NEW
Product: MediaWiki
Classification: Unclassified
Watchlist (Other open bugs)
1.11.x
All All
: Low normal with 16 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 11596 23288 23309 34163 54154 57797 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-04 10:24 UTC by Jelte (WebBoy)
Modified: 2014-11-18 18:07 UTC (History)
25 users (show)

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


Attachments

Description Jelte (WebBoy) 2007-05-04 10:24:49 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.
Comment 1 Rob Church 2007-06-05 01:54:06 UTC
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.
Comment 2 Jelte (WebBoy) 2007-10-08 14:23:47 UTC
*** Bug 11596 has been marked as a duplicate of this bug. ***
Comment 3 Roan Kattouw 2007-10-08 14:29:30 UTC
(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
Comment 4 gsv 2007-12-08 20:28:43 UTC
(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.
Comment 5 Brion Vibber 2007-12-18 01:06:31 UTC
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
Comment 6 Ilmari Karonen 2008-10-15 12:37:12 UTC
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.
Comment 7 Ilmari Karonen 2008-10-15 15:10:29 UTC
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.)
Comment 8 Ilmari Karonen 2008-10-15 16:49:35 UTC
...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;
Comment 9 Siebrand Mazeland 2009-02-02 11:42:12 UTC
Changing component to "Watchlist"
Comment 10 Roan Kattouw 2010-04-24 16:40:35 UTC
*** Bug 23309 has been marked as a duplicate of this bug. ***
Comment 11 Krinkle 2010-09-27 14:06:27 UTC
Any progress on this ? Ilmari Karonen's query works according to him. Perhaps put this to more testing and/or implementation.
Comment 12 Rich Farmbrough 2010-10-26 02:21:40 UTC
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.
Comment 13 Nemo 2011-10-20 22:16:17 UTC
*** Bug 8965 has been marked as a duplicate of this bug. ***
Comment 14 TMg 2012-03-22 19:15:50 UTC
Reported 5 years ago and still NEW? It seems everybody understands the problem. Why not fix it?
Comment 15 Nemo 2012-05-12 06:44:49 UTC
*** Bug 34163 has been marked as a duplicate of this bug. ***
Comment 16 nought_0000 2013-09-08 04:08:03 UTC
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.
Comment 17 TMg 2013-09-08 13:41:42 UTC
(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.
Comment 18 Bartosz Dziewoński 2013-09-15 17:06:08 UTC
*** Bug 54154 has been marked as a duplicate of this bug. ***
Comment 19 Peter Coombe 2013-12-02 14:29:02 UTC
*** Bug 57797 has been marked as a duplicate of this bug. ***
Comment 20 Ian Tresman 2013-12-02 14:41:42 UTC
It would make better sense if preferences "Ignored bots", otherwise you can miss recent changes.

Likewise it should be "ignore minor edits".
Comment 21 Nemo 2014-06-01 12:50:00 UTC
*** Bug 23288 has been marked as a duplicate of this bug. ***
Comment 22 steelpillow 2014-06-01 13:16:24 UTC
(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.
Comment 23 fgnievinski 2014-11-02 03:08:08 UTC
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!
Comment 24 fgnievinski 2014-11-02 03:11:56 UTC
(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".
Comment 25 Eric 2014-11-18 00:58:58 UTC
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.

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


Navigation
Links