The original patch didn't work, but the new patch should.

Found it! The change in 1.32.0-wmf.24 that changed the behavior was rECHOb82b54f0a6ef: Don't override checkmatrix defaults set elsewhere, which was a fix for T174220: [Spike 8 hours] Successful login notification gets sent out even when disabled in preferences. Echo was overriding the default values for all echo-subscription-web-* preferences and forcing them to true even if they were configured to be false. So the default value for this preference did change, just not in a way that was apparent from looking at the git history.

I found this task and its fix in the context of T220762: [betalabs] Stuck cross-wiki notification , and I have a theory for why this was so hard to reproduce: the default value of the preference was forced to true by the Echo code Max removed, but on the preferences form the checkbox for the preference was rendered as unchecked (and disabled). So if a user then submits the preferences form, the preference becomes disabled. This suggests that the bug would only have happened for users who had never changed/saved their preferences (or on wikis where they had never changed/saved their preferences).

It appears that something happened in 1.32.0-wmf.24 that caused us to stop inserting these notifications:

2018-10-03 21:16 dduvall@deploy1001: rebuilt and synchronized wikiversions files: group1 wikis to 1.32.0-wmf.24
2018-10-04 19:26 dduvall@deploy1001: rebuilt and synchronized wikiversions files: all wikis to 1.32.0-wmf.24

I looked at a few large wikis, and on all of them the timestamp of the last login-success notification is right before wmf.24 was enabled on that wiki: 20181004192550 on enwiki, 20181004192150 on dewiki, 20181003210113 on commonswiki and 20181003211300 on wikidatawiki.

I haven't been able to reproduce this problem, or otherwise figure out how it was possible for a web notification for login-success to be inserted into the database, counted in the notification count, and then become disabled without the notification count being recomputed. In particular I found the following things:

• Web notifications for login-success are disallowed ($wgNotifyTypeAvailabilityByCategory['login-success']['web'] is false), and have always been as far as I can tell
• If the user's echo-subscription-web-login-success preference is enabled, a web notification will be inserted despite this category+notifyType combination being disallowed (I wrote a patch that fixes this). This sounds promising, but...
• Subscription preferences for disallowed category-notifyType pairs (like web-login-success) are forced to false, and have always been as far as I can tell, meaning the user can't enable them
• If the user somehow did enable this preference, that wouldn't cause this bug, because then the login-success notification would just be visible. So the preference must have become disabled again after the notification was inserted.
• But any change in a user's settings triggers a notification count recomputation, which would have made the bug go away.
• Maybe the default value for this preference changed? That could change the effective value of the preference without running the saveSettings hook.
• But as far as I can tell, the default value of this preference has always been false.

BTW @Niharika is it intentional that login-success notifications are not deliverable through the web (only by email), and users cannot choose for them to be web-delivered even if they want to? If it is intentional, I'd recommend this config be moved from CommonSettings.php into the extension.

As you say, this is a login-success notification. Web delivery is disabled for these notifications (not in LoginNotify itself, but in WMF config: rOMWC4f3bfc93b785: Config changes for LoginNotify). So it makes sense that a login-success notification that's in the database will not be rendered, and will cause problems.

Well, this is interesting:

Caused by rEORS94634a01aede: Move classes around so namespaces don't couple tightly to each other

In T219684#5099170, @dbarratt wrote:

Oh... it looks like it hasn't been in a released version yet... so if that's the case, no deprecation needed. :)

It also uses a questionable definition of "newbie": user accounts that are in the most recently-created 1% (i.e. whose user ID is greater than 0.99*highestUserID)

The patch above addresses all of these things except for the subheader thing, because I'm confused about what you want there (see inline):

It turns out email subjects are a complete disaster gender-wise, and with the notable exception of Wikidata, no notification type or extension was getting this right. The patch above fixes the issue as reported, but there's a bunch more stuff to clean up, so it won't be the last patch on this task.

I just tried this myself on testwiki and it turns out that the email body uses the correct gender, but the subject line is wrong:

These look good to me. I'm on the fence as to whether the goodfaith likelybad level should be at precision>=0.6 or precision>=0.75 (as it is, the maybebad and likelybad levels are kind of close together), but for maintainability it might be better to stick with the defaults and let this strangeness sort itself out if/when the model is rebuilt in the future.

Note that this button is defined twice, once in PHP and once in JS. See "editButton" in includes/OOUI/BoardDescriptionWidget.php and modules/flow/ui/widgets/mw.flow.ui.BoardDescriptionWidget.js respectively. Both need to have the progressive flag removed.

However, now that we have tags for edits that make a page into a redirect, or change a redirect's target, or change a redirect to a non-redirect, it would be possible to look for those tags and add a redirect symbol as this task proposes.

What's the proposed alternative? A table where each cell contains either nothing or one character?

Page subheader > colorGray7

It turns out we're using MediaWiki's built-in page subheader feature, which uses colorGray5 instead.