Last modified: 2014-09-23 23:13:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T29884, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27884 - enotif doesn't send email if page on watchlist edited following a minor edit and enotif not configured to send minor edits.
enotif doesn't send email if page on watchlist edited following a minor edit ...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Email (Other open bugs)
1.21.x
All All
: Normal major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
: 42482 (view as bug list)
Depends on:
Blocks: 1932
  Show dependency treegraph
 
Reported: 2011-03-06 03:37 UTC by Bawolff (Brian Wolff)
Modified: 2014-09-23 23:13 UTC (History)
5 users (show)

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


Attachments
patch to not update wl_timestamp on minor edits, if $wgEnotifMinorEdits = false. (875 bytes, patch)
2011-03-06 09:02 UTC, Bawolff (Brian Wolff)
Details

Description Bawolff (Brian Wolff) 2011-03-06 03:37:17 UTC
Steps to reroduce:
*Make sure enotif is configured to not send emails on minor edits. $wgEnotifMinorEdits=false and/or relevent stuff in your prefs.
*Add page foo to your watchlist.
*With another account, edit foo setting your edit to be minor.
*Edit again, this time not as minor

Result: no email is sent

Expected result: email sent on the non-minor edit.

This is caused because enotif tries to send only a single email if a page is edited multiple times without the watcher viewing it. The first (minor) edit does not trigger an email since its minor, the second edit does not trigger an email since the watcher hasn't viewed the page since the first (minor) edit.
Comment 1 Bawolff (Brian Wolff) 2011-03-06 09:02:40 UTC
Created attachment 8255 [details]
patch to not update wl_timestamp on minor edits, if $wgEnotifMinorEdits = false.

Hmm, looks like we could maybe just not update wl_timestamp on minor edits if the wiki is globally configured not to send emails on minor edits. This would probably cut back on the job queue usage significantly on such wikis.

Here's a patch that does that. I need to figure out how exactly wl_timestamp is actually used before i'd feel confident committing though.

Also this wouldn't fix it for wikis that enable sending on minor edits, but where the user disabled in prefs.
Comment 2 Sumana Harihareswara 2011-11-09 03:08:07 UTC
+need-review to signal to developers that this patch needs reviewing
Comment 3 Rob Moen 2012-01-14 01:38:16 UTC
Thank you for the patch.  The bug appears to still exist based on looking on the code and my initial tests.  However, the patch is outdated and will not apply to the current state of trunk.  If you are still interested, you are welcome to revise the patch to be applied to the trunk.

Marked as reviewed.
Comment 4 Bawolff (Brian Wolff) 2012-01-16 00:27:25 UTC
This patch would (probably) be trivial to update. Downside is this will break the "bold" there are updates available marker on watchlist (or actually not so much break it, but make its behaviour kind of weird for minor edits). OTOH the updated marker should probably be re-thought on a variety of fronts... (not user controllable, not reset from email links half the time, not clear to user what it even means).
Comment 5 Richard Guk 2012-12-04 15:35:34 UTC
This bug is live the current version and still needs fixing.

At present, a minor update will indefinitely suppress all subsequent watchlist emails for that page (until the user visits it or resets the visit flag, which might never happen if the user is unaware of this bug). It is perverse that a "minor" update has such a major lasting effect on the email flag.

(In reply to comment #4)
> This patch would (probably) be trivial to update. Downside is this will break
> the "bold" there are updates available marker on watchlist (or actually not so
> much break it, but make its behaviour kind of weird for minor edits).

If there has to be a choice between fixing this bug and preserving the above formatting, it is more important to ensure that users are emailed reliably by fixing this bug.

From a user's perspective, the bug is causing pages to unpredictably and silently drop off their email notification list. That is an appalling user experience.

>                                                                       OTOH the
> updated marker should probably be re-thought on a variety of fronts... (not
> user controllable, not reset from email links half the time, not clear to user
> what it even means).

Watchlists would be much more intuitive if they only showed changes *since* a user-defined timestamp. That way, a user could click a button after checking their watchlist, and return at a future time to see all subsequent changes, without having to adjust the "days" parameter or remember how long it was since they had last checked it. (Similar functionality already exists in [[Special:RecentChanges]], e.g. [[Special:RecentChanges?from=20121204150102]], except that the "from" timestamp is not stored.) Is there a separate bug open for that?
Comment 6 Richard Guk 2012-12-04 15:53:43 UTC
(In reply to comment #5)
> Watchlists would be much more intuitive if they only showed changes *since* a
> user-defined timestamp. That way, a user could click a button after checking
> their watchlist, and return at a future time to see all subsequent changes,
> without having to adjust the "days" parameter or remember how long it was since
> they had last checked it. (Similar functionality already exists in
> [[Special:RecentChanges]], e.g. [[Special:RecentChanges?from=20121204150102]],
> except that the "from" timestamp is not stored.) Is there a separate bug open
> for that?

I have raised the above suggestion under Bug 4903.

Anyway, the email bug here needs fixing in its own right.
Comment 7 Sumana Harihareswara 2012-12-28 01:05:37 UTC
Adding the bug wrangler to ask him to look into this next week; raising the severity.
Comment 8 Andre Klapper 2012-12-31 11:59:53 UTC
I guess this needs more thoughts and input before anybody can come up with an updated patch - see comments 4 and 5.
Comment 9 T. Gries 2012-12-31 12:19:19 UTC
I as the original designer of "enotif" stay usually silent. i.e. I usually do not comment on these "enotif is broken on this and that" bugs - they all document (let's call it) regressions from the original design (dating back to 2004). This is not a complain or so, just wanted to say that I'm not away and will help if this is needed.

I hope that all these issues are solved in the near future.
Comment 10 Nemo 2013-06-11 07:27:56 UTC
*** Bug 42482 has been marked as a duplicate of this bug. ***

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


Navigation
Links