Page MenuHomePhabricator

enotif doesn't send email if page on watchlist edited following a minor edit and enotif not configured to send minor edits.
Open, HighPublic

Tokens
"Like" token, awarded by Nesnera."Baby Tequila" token, awarded by RandomDSdevel."Like" token, awarded by Liuxinyu970226."Like" token, awarded by Julle."Like" token, awarded by scfc."Manufacturing Defect?" token, awarded by Dalba.
Assigned To
None
Authored By
Bawolff, Mar 6 2011

Description

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.


See Also:
T40874: Minor bot edits don't trigger email notifications even with "E-mail me also for minor edits of pages" selected

Details

Reference
bz27884
Related Gerrit Patches:

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:35 PM
bzimport added a project: MediaWiki-Email.
bzimport set Reference to bz27884.
bzimport added a subscriber: Unknown Object (MLST).
Bawolff created this task.Mar 6 2011, 3:37 AM

Created attachment 8255
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.

Attached:

sumanah wrote:

+need-review to signal to developers that this patch needs reviewing

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.

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

richardg_uk wrote:

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?

richardg_uk wrote:

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

sumanah wrote:

Adding the bug wrangler to ask him to look into this next week; raising the severity.

I guess this needs more thoughts and input before anybody can come up with an updated patch - see comments 4 and 5.

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.

  • Bug 42482 has been marked as a duplicate of this bug. ***
scfc added a subscriber: scfc.Aug 31 2015, 2:34 PM
Dalba awarded a token.Dec 28 2015, 6:25 AM
Dalba added a subscriber: Dalba.

According to Manual:$wgEnotifMinorEdits, even after this variable is set to true

Users still need to opt in by checking the appropriate user preference.

My question is why this setting that seems pretty safe to be enabled, is set to false by default? What are the consequences of changing the default value to true? If not much, I would suggest to set it to true by default so that users be able to manually activate the relevant setting in their preferences and avoid this bug until someone figures out a way to fix this.

scfc awarded a token.Feb 26 2017, 6:28 PM
scfc added a comment.Feb 26 2017, 6:32 PM

According to Manual:$wgEnotifMinorEdits, even after this variable is set to true

Users still need to opt in by checking the appropriate user preference.

My question is why this setting that seems pretty safe to be enabled, is set to false by default? What are the consequences of changing the default value to true? If not much, I would suggest to set it to true by default so that users be able to manually activate the relevant setting in their preferences and avoid this bug until someone figures out a way to fix this.

That issue is handled as T142727 where I've subscribed you.

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

We might need to split wl_notificationtimestamp into two columns. E.g. wl_notificationtimestamp and wl_email_notification_timestamp, so we can set wl_notificationtimestamp (on minor edits) and not wl_email_notification_timestamp (if "don't email on minor edits" is set).

Hmmm, are you really sure that it is not a simple (and real) "bug"? Adding another column would make the whole code, and database scheme, even more complicated. (I need to check the issue in a reference wiki implementation. Later.)

Change 368113 had a related patch set uploaded (by Mattflaschen; owner: Mattflaschen):
[operations/mediawiki-config@master] Make emails for minor edits always available; keep defaults

https://gerrit.wikimedia.org/r/368113

If we can't track this down soon, I think we should set it default-true everywhere, and even hide the preference.

Mattflaschen-WMF raised the priority of this task from Normal to High.Jul 26 2017, 11:52 PM

Also this wouldn't fix it for wikis that enable sending on minor edits, but where the user disabled in prefs.

Rows in the watchlist table are per-user, so the updating behavior can (and may need to) vary based on user preferences.

Change 368113 merged by jenkins-bot:
[operations/mediawiki-config@master] Make emails for minor edits always available; keep defaults

https://gerrit.wikimedia.org/r/368113

Mentioned in SAL (#wikimedia-operations) [2017-07-27T23:35:23Z] <catrope@tin> Synchronized wmf-config/: Enable emails for minor edits everywhere but keep default prefs (T29884, T142727) (duration: 00m 45s)

On all WMF wikis, you can now at least work around this by checking "Email me also for minor edits of pages and files" at the bottom of the first tab ("User profile") of Preferences.

Matt, that's good, thanks. Johan, should this go into Tech News? If now is late, even next week? TY!

Now that you say it, probably.

Liuxinyu970226 awarded a token.
Liuxinyu970226 added a subscriber: Liuxinyu970226.
Anomie added a subscriber: Anomie.Aug 7 2017, 9:50 PM
matej_suchanek updated the task description. (Show Details)
matej_suchanek removed a subscriber: wikibugs-l-list.
Blahma added a subscriber: Blahma.Sep 19 2018, 7:48 PM
Blahma removed a subscriber: Blahma.
Blahma added a subscriber: Blahma.