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

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.

In T29884#1909802, @Dalba wrote:

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.

In T29884#336569, @Bawolff wrote:

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.

In T29884#336539, @Bawolff wrote:

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.

@Johan @Elitre

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.