When notifications are being moderated, the unread count
for affected users has to be recalculated.
It was initially done using DB_SLAVE but it was leading
to inconsistent data since that database did not know
about recently deleted notifications.
It was changed to DB_MASTER but it potentially led
to too many queries on master.
This patch tries to wait for the replica to have
caught up with those changes and use it to update
the unread count for the affected users.
Bug: T93673
Change-Id: Ib4a845e82f686dd7ed807ab21a28490014b56604
At the time that resetNotificationCount() is called, we've only
just moderated something, so the slave won't have those changes yet,
and the computed notification count will be wrong.
Change-Id: Ia83f2b9cf7f4bbaee25e03f7bc8f73bcd4d345f9
* When a page is deleted, moderate associated
notifications. When it is undeleted, unmoderate.
* When a notification cannot be rendered
(canRender() returns false), moderate it.
The biggest advantage of moderation over mark-read-and-ignore
is that those notifications are filtered out at the database
level from this point on. They are not re-processed every single
time and do not affect the number of notifications returned by
the API.
Bug: T140327
Bug: T140836
Bug: T141463
Change-Id: Idefe78408fd584c13aaa9174cee3055539d92848
Followup to I639b9d9906d3ff37021cb9b5ed3cb401354b5bd9
* Remove deprecated formatter
* Log a warning and fail gracefully
when an event type does not support
Echo presentation model.
Bug: T121612
Change-Id: Ic5712c4ce265b6faabce7a4028b4294fe3c73f18
To allow individual notifications to be
marked as read/unread or moderated,
bundles are created by grouping associated
notifications when they are fetched for display
instead of when they are created.
From a product perspective, this change doesn't
introduce moderation or expandable bundles but
it counts each individual notifications.
For instance, the bundled notification
"3 new topics on PageA" now counts as 3
notifications.
Bug: T93673
Bug: T120153
Change-Id: Iacd098573efd92bb1e3fcd7da4cd40cea9522f15
Merge and deploy at the *same time* as:
* BounceHandler - I3c669945080d8e1f67880bd8a31af7f88a70904d
* mediawiki-config - I13817c139967ed9e230cfb0c87c5de66da793c96
Despite claiming to be about categories, $wgEchoDefaultNotificationTypes
was actually configuring both categories and types (which go inside
categories).
For example, 'thank-you-edit' is a type, but 'emailuser' is both
a category and a type (when used as a category, this has special
effects at Special:Preferences).
Since types and categories can and sometimes do have the same names,
this leaves no way to properly and clearly configure them. It also
makes it difficult to document what is going on (as required by
T132127).
Split into three variables:
$wgDefaultNotifyTypeAvailability - Applies unless overriden
$wgNotifyTypeAvailabilityByCategory - By category; this can be and is
displayed at Special:Preferences
$wgNotifyTypeAvailabilityByNotificationType - By type; this cannot
be displayed at Special:Preferences. To avoid confusing the user,
we introduce a restriction (which was previously followed in practice,
AFAICT) that types can only be overridden if the category is not
displayed in preferences.
Otherwise, it can look to the user like a category is on/off, but the
types within might have the opposite state.
Due to this configuration change, this is a breaking change, and needs
coordinated deployments.
This also lays the groundwork for T132127
Also change terminology to consistently use "notify type" for web/email.
It was mixing between that and output format (which unfortunately
sounds like the API format, e.g. 'model').
Bug: T132820
Bug: T132127
Change-Id: I09f39f5fc5f13f3253af9f7819bca81f1601da93
This involves:
* Making this value no longer admin-configurable.
* Changing getNotificationCountForOutput to return only a single value
Since there is no + in the formatted value anymore, we can actually
use the same value for both.
This is a B/C break, but hopefully worth it to simplify the method
call.
For now, the excess parameter is just marked unused. It could be
removed at some point if the translations are updated.
This must be merged at the same time as:
* Flow - Ibfa56b1af9e8c56b4c5f900e0d487bc09688b2a2
* MobileFrontend - Ibf784b279d56773a227ff261b75f2b26125bbb63 (well, MF
can be merged first)
* translatewiki - I2a4b6938aed49e4101deb6b9351c43656a863490
Also, change 1 to One/one, per Siebrand on the task. This can easily
be dropped/undone if we don't want it.
Also, remove reference to no-longer-existent notification-page-linked-bundle
Bug: T127288
Change-Id: Iabeaae747f99980c0610d552f6b38f89d940b890
Objects can be different instances (and for User, they can contain
very different data) in which case they wouldn't be recognized even
if they were the same user.
Let's find by ID instead.
Bug: T124803
Change-Id: Ia166fd4190f264354cea83d98047c62c7e0714ea
Right now, if certain users should be excluded, that would have
to be part of the user-locators already. This is annoying because
it's hard to write "generic" user locators when you want to exclude
just a couple of people in certain cases.
In Flow, for example, we have user-locators for users watching a
board or topic. We don't want to send the notification to people
that have also been mentioned in that post (they'll get a separate
notification). We could build that exception into those
user-locators, but then we couldn't re-use them in other places...
This basically means we couldn't use EchoUserLocator::locateUsersWatchingTitle,
we would have to roll our own that also excludes mentioned users.
Instead, this lets you add 'user-filters' (that functionality
actually exists already, but is not currently exposed), which
lists users to not send the notification to, even though they could
be in a user-locator.
Bug: T125428
Change-Id: Ifa0e2d3283f57624af4c5ec264f9f66223508e83
Adds EchoEventPresentationModel::canRender() for notification types to
indicate that something can't be rendered if for example, a page is
deleted.
In that case, the notification is marked as read in a deferred update.
All callers were also updated to check if the notification was formatted
properly.
Bug: T116888
Change-Id: Idb975feaec893ef86c41cc487102e3539c07e328
Push the $wgEchoNotifications dependency to
NotificationFormatter::factory(), and only catch exceptions we're
actually expecting (NotificationFormatter::format()).
And clean up the logging to use structured logging while we're at it.
Change-Id: I7e18c318c5c81b6a38e55f27ef8f604654f10858
