Adds additional job parameters to help diagnose the apparent issue of
jobs being performed twice on Beta.
Bug: T255068
Change-Id: Ib257a24056539487e1110fe286fa4535c3fec94a
It is the notifier implementation's responsibility to check the user's
notification preferences before sending a notification. This adds the
check.
Change-Id: I4b7fd7ea444f5a6db6d79fadb48a440d4fdf0ac9
The nicer approach would be setting the parameter default to [],
but that breaks ApiSandbox.
Bug: T254699
Change-Id: I6c553e27248ff7d6c696f116cb34eb238dade440
Rather than catching all DB errors (and assuming they are duplicate
entry errors), ignore duplicate entry errors and use affectedRows() to
determine whether the subscription already existed.
Change-Id: I4d50cb8222e52cc1a4e1f0fb3f596f36cb565dbb
Finishes the implementation of the stubbed NotificationServiceClient.
Sends push notification request messages to the endpoint configured in
the EchoPushServiceBaseUrl setting. For example, to send messages to an
instance of mediawiki/services/push-notifications running on the host
machine while running MediaWiki in Docker, add the following line to
LocalSettings.php:
$wgEchoPushServiceBaseUrl = 'http://172.17.0.1:8900/v1/message';
Bug: T252899
Change-Id: Icab7825e9080d6b1a4cfc5e12fed1da221ce4610
Updates the push subscription query to retrieve a provider string rather
than only its numeric internal ID.
Change-Id: I910173409e48e8b6a6739d3122165c40b0d52b7f
Provides a basic push notifier implementation. Since the push service is
not yet in place, all it does for now is log debug output when a
notification is to be sent.
To register the push notifier, add the following configuration to
LocalSettings.php:
$wgEchoNotifiers['push'] = [ 'EchoPush\\PushNotifier', 'notifyWithPush' ];
$wgDefaultNotifyTypeAvailability['push'] = true;
$wgNotifyTypeAvailabilityByCategory['system']['push'] = false;
$wgNotifyTypeAvailabilityByCategory['system-noemail']['push'] = false;
We'll register the notifier in configuration for now, rather than
hard-coding the default in extension.json, in order to have control over
when and where it rolls out (beta vs. prod, as well as which wikis).
Since the push notifier implementation depends on jobs being processed
by the job queue, I also recommend adding the following configuration
setting to ensure that all pending jobs are processed at the end of each
web request:
// ensure all pending jobs are processed when a web request completes
$wgJobRunRate = PHP_INT_MAX;
Bug: T252899
Change-Id: Ie7f222443045d30620ff297b006104ef18a074a8
Adds DB tables for storing push subscriptions, some DB interaction code
for retrieving them within MediaWiki, and a set of API modules for
managing them from the outside world.
When testing this patch, be sure to run maintenance/update.php to create
the new tables, and set $wgEchoEnablePush = true in LocalSettings.php
to enable the API new API module.
N.B. The current DB schema is centered on app push subscriptions. Web
push subscriptions require slightly different handling, since they are
provided by browsers as a JSON blob rather than a token string. How to
handle web push subscriptions is a question we can defer until the time
comes to add web push support.
Subscription data is stored in the echo_push_subscription table, with
provider names normalized into the echo_push_provider table. We expect to
be looking up subscriptions by central user ID, so that column is indexed.
The subscription data also includes a column to store SHA256 digests of
the subscriber tokens. This is for use as a unique key constraint, since
we expect every push token to be univerally unique, and the token values
themselves may be too large to reasonably index in MySQL.
Bug: T252899
Change-Id: I3928761b3fba12e54ff4850e9a05c68ec7772f62
Use the globally configured request timeout instead of MultiHttpClient's
hard-coded default. This means that the request timeout for
ForeignWikiRequest will typically be reduced from 900s to 25s.
Bug: T245170
Depends-On: I8252f6c854b98059f4916d5460ea71cf4b580149
Change-Id: I1c3d96720709253ad15bb8528cdd132571de2e4e
* Add a section on the preference form to allow users to mute articles
from generating "page linked" notices
* The preference will save the article title as an article ID
Depends-On: Ia0ddf78646ec4c8ae0b84b6d5b46ef5e51c8e8c1
Bug: T46787
Change-Id: I67f751eae5fdc5bccff7fe3047227d432c1cb8d5
DiscussionParser::getUserMentions() returns mentions in an array of the
form [ID => ID]. UserLocator says "we shouldn't receive User instances,
but allow it for backward compatability". But
DiscussionParser::generateEventsForRevision() was putting User objects
into the extra when there is a mention in the edit summary.
I noticed this when I accidentally made User objects be unserializable
in a core patch.
So, I made generateEventsForRevision() generate mention arrays in the
same ID=>ID format as getUserMentions().
Change-Id: I7c6d25950c8887b50426863c7b0a2d5d007559dd
1. Preamble:
Currently Extension:Echo unconditionally suppresses NewMessagesAlert,
because "You have new messages" is replaced by Echo notification.
2. Problem:
Some third-party extensions (such as Extension:Moderation) can use
GetNewMessagesAlert hook to inject their own notification, which must
not be suppressed.
By returning "false" from GetNewMessagesAlert hook, Echo stops those
third-party extensions from showing their notifications too.
3. Solution:
Allow those third-party extension to tell Echo "don't suppress this"
by returning false from the hook EchoCanAbortNewMessagesAlert.
This change has no impact on situations when no such third-party
extensions are installed.
4. How it was handled before this change:
Old solution for those extensions was to remove the hook of Echo from
$wgHooks, which was a dirty hack and is not compatible with T240307.
Change-Id: I433e30c5f639b5f20838804e8fa7c94a4bcf5349
There are cases where we want to vary on $distributionType what is sent.
If it's an email (for example), we might want more information and
context which is unneeded via the web notification.
Bug: T249408
Change-Id: I68cedfa8389e1d935b02ca7475bf42262005d2bc
