Watchlist doesn't show earlier normal edits when hiding bot edits or minor edits
OpenPublic

Assigned To
None
Priority
Normal
Author
bzimport
Subscribers
MZMcBride, liangent, matmarex and 11 others
Projects
Tokens
"Love" token, awarded by He7d3r.
Reference
bz9790
Security
None
Description

Author: webboy

Description:
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.


Version: 1.11.x
Severity: normal

bzimport added a project: MediaWiki-Watchlist.Via ConduitNov 21 2014, 9:40 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz9790.
bzimport created this task.Via LegacyMay 4 2007, 10:24 AM
bzimport added a comment.Via ConduitJun 5 2007, 1:54 AM

robchur wrote:

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.

bzimport added a comment.Via ConduitOct 8 2007, 2:23 PM

webboy wrote:

*** Bug 11596 has been marked as a duplicate of this bug. ***

Catrope added a comment.Via ConduitOct 8 2007, 2:29 PM

(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

bzimport added a comment.Via ConduitDec 8 2007, 8:28 PM

gsv wrote:

(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.

brion added a comment.Via ConduitDec 18 2007, 1:06 AM

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

Ilmari_Karonen added a comment.Via ConduitOct 15 2008, 12:37 PM

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.

Ilmari_Karonen added a comment.Via ConduitOct 15 2008, 3:10 PM

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.)

Ilmari_Karonen added a comment.Via ConduitOct 15 2008, 4:49 PM

...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;

siebrand added a comment.Via ConduitFeb 2 2009, 11:42 AM

Changing component to "Watchlist"

Catrope added a comment.Via ConduitApr 24 2010, 4:40 PM
  • Bug 23309 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Via ConduitSep 27 2010, 2:06 PM

Any progress on this ? Ilmari Karonen's query works according to him. Perhaps put this to more testing and/or implementation.

Rich_Farmbrough added a comment.Via ConduitOct 26 2010, 2:21 AM

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.

Nemo_bis added a comment.Via ConduitOct 20 2011, 10:16 PM
  • Bug 8965 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMar 22 2012, 7:15 PM

mr.heat wrote:

Reported 5 years ago and still NEW? It seems everybody understands the problem. Why not fix it?

Nemo_bis added a comment.Via ConduitMay 12 2012, 6:44 AM
  • Bug 34163 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitSep 8 2013, 4:08 AM

nought_0000 wrote:

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.

bzimport added a comment.Via ConduitSep 8 2013, 1:41 PM

mr.heat wrote:

(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.

matmarex added a comment.Via ConduitSep 15 2013, 5:06 PM
  • Bug 54154 has been marked as a duplicate of this bug. ***
Pcoombe added a comment.Via ConduitDec 2 2013, 2:29 PM
  • Bug 57797 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitDec 2 2013, 2:41 PM

ian2 wrote:

It would make better sense if preferences "Ignored bots", otherwise you can miss recent changes.

Likewise it should be "ignore minor edits".

Nemo_bis added a comment.Via ConduitJun 1 2014, 12:50 PM
  • Bug 23288 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJun 1 2014, 1:16 PM

guy wrote:

(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.

Fgnievinski added a comment.Via ConduitNov 2 2014, 3:08 AM

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!

Fgnievinski added a comment.Via ConduitNov 2 2014, 3:11 AM

(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".

bzimport added a comment.Via ConduitNov 18 2014, 12:58 AM

e.martinson wrote:

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.

He7d3r awarded a token.Via WebNov 24 2014, 12:07 PM
MZMcBride added a subscriber: MZMcBride.Via WebJan 14 2015, 9:40 PM
Nemo_bis raised the priority of this task from "Low" to "Normal".Via WebJan 16 2015, 9:38 PM
Nemo_bis added a project: Epic.
Nemo_bis set Security to None.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.