2012-04-27 15:14:24 +00:00
|
|
|
<?php
|
|
|
|
/**
|
|
|
|
* MediaWiki Extension: Echo
|
2013-08-28 17:38:52 +00:00
|
|
|
* http://www.mediawiki.org/wiki/Extension:Echo
|
2012-04-27 15:14:24 +00:00
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* This program is distributed WITHOUT ANY WARRANTY.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
*
|
|
|
|
* @file
|
|
|
|
* @ingroup Extensions
|
2013-08-28 17:38:52 +00:00
|
|
|
* @author Andrew Garrett, Benny Situ, Ryan Kaldari, Erik Bernhardson
|
|
|
|
* @licence MIT License
|
2012-04-27 15:14:24 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
# Alert the user that this is not a valid entry point to MediaWiki if they try to access the special pages file directly.
|
|
|
|
if ( !defined( 'MEDIAWIKI' ) ) {
|
|
|
|
echo <<<EOT
|
|
|
|
To install this extension, put the following line in LocalSettings.php:
|
|
|
|
require_once( "$IP/extensions/Echo/Echo.php" );
|
|
|
|
EOT;
|
|
|
|
exit( 1 );
|
|
|
|
}
|
|
|
|
|
|
|
|
// Extension credits that will show up on Special:Version
|
|
|
|
$wgExtensionCredits['specialpage'][] = array(
|
|
|
|
'path' => __FILE__,
|
|
|
|
'name' => 'Echo',
|
2012-12-14 16:49:06 +00:00
|
|
|
'url' => 'https://www.mediawiki.org/wiki/Extension:Echo',
|
2015-12-16 00:30:19 +00:00
|
|
|
'author' => array( 'Andrew Garrett', 'Ryan Kaldari', 'Benny Situ', 'Luke Welling', 'Kunal Mehta', 'Moriel Schottlender', 'Jon Robson' ),
|
2012-04-27 15:14:24 +00:00
|
|
|
'descriptionmsg' => 'echo-desc',
|
2015-01-29 13:58:09 +00:00
|
|
|
'license-name' => 'MIT',
|
2012-04-27 15:14:24 +00:00
|
|
|
);
|
|
|
|
|
2014-03-26 14:22:57 +00:00
|
|
|
$wgMessagesDirs['Echo'] = __DIR__ . '/i18n';
|
2015-06-16 00:45:03 +00:00
|
|
|
$wgExtensionMessagesFiles['EchoAliases'] = __DIR__ . '/Echo.alias.php';
|
2012-04-27 15:14:24 +00:00
|
|
|
|
2014-09-26 21:42:19 +00:00
|
|
|
// This file is autogenerated by scripts/gen-autoload.php
|
|
|
|
require __DIR__ . "/autoload.php";
|
2012-04-27 15:14:24 +00:00
|
|
|
|
2014-09-26 21:42:19 +00:00
|
|
|
// Queable jobs
|
2012-06-06 07:04:28 +00:00
|
|
|
$wgJobClasses['EchoNotificationJob'] = 'EchoNotificationJob';
|
2013-03-06 00:04:48 +00:00
|
|
|
$wgJobClasses['MWEchoNotificationEmailBundleJob'] = 'MWEchoNotificationEmailBundleJob';
|
2014-09-09 22:11:53 +00:00
|
|
|
// Job to delete older notifications
|
|
|
|
$wgJobClasses['EchoNotificationDeleteJob'] = 'EchoNotificationDeleteJob';
|
2012-06-06 07:04:28 +00:00
|
|
|
|
2012-04-27 15:14:24 +00:00
|
|
|
// API
|
|
|
|
$wgAPIMetaModules['notifications'] = 'ApiEchoNotifications';
|
2016-05-27 21:10:04 +00:00
|
|
|
$wgAPIMetaModules['unreadnotificationpages'] = 'ApiEchoUnreadNotificationPages';
|
2013-09-18 21:10:37 +00:00
|
|
|
$wgAPIModules['echomarkread'] = 'ApiEchoMarkRead';
|
2015-04-29 12:08:30 +00:00
|
|
|
$wgAPIModules['echomarkseen'] = 'ApiEchoMarkSeen';
|
2012-04-27 15:14:24 +00:00
|
|
|
|
|
|
|
// Special page
|
|
|
|
$wgSpecialPages['Notifications'] = 'SpecialNotifications';
|
2016-04-19 03:06:03 +00:00
|
|
|
$wgSpecialPages['DisplayNotificationsConfiguration'] = 'SpecialDisplayNotificationsConfiguration';
|
2016-03-09 20:13:48 +00:00
|
|
|
$wgSpecialPages['NotificationsMarkRead'] = 'SpecialNotificationsMarkRead';
|
2012-04-27 15:14:24 +00:00
|
|
|
|
|
|
|
// Housekeeping hooks
|
2015-06-02 00:28:25 +00:00
|
|
|
$wgHooks['LoadExtensionSchemaUpdates'][] = 'EchoHooks::onLoadExtensionSchemaUpdates';
|
2012-04-27 15:14:24 +00:00
|
|
|
$wgHooks['GetPreferences'][] = 'EchoHooks::getPreferences';
|
2012-06-01 10:57:09 +00:00
|
|
|
$wgHooks['PersonalUrls'][] = 'EchoHooks::onPersonalUrls';
|
|
|
|
$wgHooks['BeforePageDisplay'][] = 'EchoHooks::beforePageDisplay';
|
2012-07-31 21:18:16 +00:00
|
|
|
$wgHooks['MakeGlobalVariablesScript'][] = 'EchoHooks::makeGlobalVariablesScript';
|
2012-07-31 00:29:49 +00:00
|
|
|
$wgHooks['UnitTestsList'][] = 'EchoHooks::getUnitTests';
|
2013-03-01 00:26:59 +00:00
|
|
|
$wgHooks['ResourceLoaderRegisterModules'][] = 'EchoHooks::onResourceLoaderRegisterModules';
|
2015-06-01 18:58:37 +00:00
|
|
|
$wgHooks['EventLoggingRegisterSchemas'][] = 'EchoHooks::onEventLoggingRegisterSchemas';
|
2014-08-05 22:18:38 +00:00
|
|
|
$wgHooks['ResourceLoaderTestModules'][] = 'EchoHooks::onResourceLoaderTestModules';
|
2015-09-22 18:16:59 +00:00
|
|
|
$wgHooks['UserGroupsChanged'][] = 'EchoHooks::onUserGroupsChanged';
|
2013-04-30 02:53:33 +00:00
|
|
|
$wgHooks['UserLoadOptions'][] = 'EchoHooks::onUserLoadOptions';
|
|
|
|
$wgHooks['UserSaveOptions'][] = 'EchoHooks::onUserSaveOptions';
|
2013-05-24 22:51:47 +00:00
|
|
|
$wgHooks['UserClearNewTalkNotification'][] = 'EchoHooks::onUserClearNewTalkNotification';
|
2014-06-26 01:04:31 +00:00
|
|
|
$wgHooks['ParserTestTables'][] = 'EchoHooks::onParserTestTables';
|
2015-09-19 20:49:34 +00:00
|
|
|
$wgHooks['EmailUserComplete'][] = 'EchoHooks::onEmailUserComplete';
|
2015-12-08 18:54:44 +00:00
|
|
|
$wgHooks['LoginFormValidErrorMessages'][] = 'EchoHooks::onLoginFormValidErrorMessages';
|
2016-05-10 23:56:07 +00:00
|
|
|
$wgHooks['OutputPageCheckLastModified'][] = 'EchoHooks::onOutputPageCheckLastModified';
|
2012-06-01 10:57:09 +00:00
|
|
|
|
2014-08-26 03:09:46 +00:00
|
|
|
// Extension:UserMerge support
|
|
|
|
$wgHooks['UserMergeAccountFields'][] = 'EchoHooks::onUserMergeAccountFields';
|
|
|
|
$wgHooks['MergeAccountFromTo'][] = 'EchoHooks::onMergeAccountFromTo';
|
|
|
|
$wgHooks['UserMergeAccountDeleteTables'][] = 'EchoHooks::onUserMergeAccountDeleteTables';
|
|
|
|
|
2013-01-15 23:21:39 +00:00
|
|
|
// Extension initialization
|
|
|
|
$wgExtensionFunctions[] = 'EchoHooks::initEchoExtension';
|
|
|
|
|
2015-06-02 00:26:36 +00:00
|
|
|
require __DIR__ . '/Resources.php';
|
2012-04-27 15:14:24 +00:00
|
|
|
|
2013-01-15 23:21:39 +00:00
|
|
|
$wgHooks['EchoGetBundleRules'][] = 'EchoHooks::onEchoGetBundleRules';
|
2013-05-01 19:27:32 +00:00
|
|
|
$wgHooks['EchoAbortEmailNotification'][] = 'EchoHooks::onEchoAbortEmailNotification';
|
2012-04-27 15:14:24 +00:00
|
|
|
|
|
|
|
// Hook appropriate events
|
|
|
|
$wgHooks['ArticleSaveComplete'][] = 'EchoHooks::onArticleSaved';
|
2016-05-25 19:03:29 +00:00
|
|
|
$wgHooks['LocalUserCreated'][] = 'EchoHooks::onLocalUserCreated';
|
2012-07-18 19:39:33 +00:00
|
|
|
$wgHooks['ArticleRollbackComplete'][] = 'EchoHooks::onRollbackComplete';
|
2013-04-12 22:12:22 +00:00
|
|
|
$wgHooks['UserSaveSettings'][] = 'EchoHooks::onUserSaveSettings';
|
2012-04-27 15:14:24 +00:00
|
|
|
|
2012-12-19 22:35:45 +00:00
|
|
|
// Disable ordinary user talk page email notifications
|
2013-06-08 01:05:35 +00:00
|
|
|
$wgHooks['AbortTalkPageEmailNotification'][] = 'EchoHooks::onAbortTalkPageEmailNotification';
|
2014-02-21 01:48:08 +00:00
|
|
|
$wgHooks['SendWatchlistEmailNotification'][] = 'EchoHooks::onSendWatchlistEmailNotification';
|
2015-06-01 23:59:03 +00:00
|
|
|
// Disable the orange bar of death
|
2013-05-05 00:49:08 +00:00
|
|
|
$wgHooks['GetNewMessagesAlert'][] = 'EchoHooks::abortNewMessagesAlert';
|
2012-12-26 22:05:29 +00:00
|
|
|
$wgHooks['LinksUpdateAfterInsert'][] = 'EchoHooks::onLinksUpdateAfterInsert';
|
2012-07-17 22:19:32 +00:00
|
|
|
|
2015-11-30 23:14:57 +00:00
|
|
|
// Beta features
|
|
|
|
$wgHooks['GetBetaFeaturePreferences'][] = 'EchoHooks::getBetaFeaturePreferences';
|
|
|
|
|
2016-02-18 22:36:58 +00:00
|
|
|
// Global config vars
|
|
|
|
$wgHooks['ResourceLoaderGetConfigVars'][] = 'EchoHooks::onResourceLoaderGetConfigVars';
|
|
|
|
|
2012-04-27 15:14:24 +00:00
|
|
|
// Configuration
|
|
|
|
|
2012-11-27 01:53:35 +00:00
|
|
|
// Whether to turn on email batch function
|
|
|
|
$wgEchoEnableEmailBatch = true;
|
2012-11-13 23:06:11 +00:00
|
|
|
|
2012-12-19 20:28:17 +00:00
|
|
|
// Whether to use job queue to process web and email notifications, bypass the queue for now
|
|
|
|
// since it's taking more than an hour to run in mediawiki.org, this is not acceptable for the
|
|
|
|
// purpose of testing notification.
|
|
|
|
$wgEchoUseJobQueue = false;
|
|
|
|
|
2012-10-25 20:39:41 +00:00
|
|
|
// The organization address, the value should be defined in LocalSettings.php
|
|
|
|
$wgEchoEmailFooterAddress = '';
|
2012-08-02 19:50:46 +00:00
|
|
|
|
2013-04-17 16:26:05 +00:00
|
|
|
// The email address for both "from" and "reply to" on email notifications.
|
|
|
|
// Should be defined in LocalSettings.php
|
|
|
|
$wgNotificationSender = $wgPasswordSender;
|
|
|
|
// Name for "from" on email notifications. Should be defined in LocalSettings.php
|
2014-02-25 06:09:27 +00:00
|
|
|
// if null, uses 'emailsender' message
|
|
|
|
$wgNotificationSenderName = null;
|
2013-04-17 16:26:05 +00:00
|
|
|
// Name for "reply to" on email notifications. Should be defined in LocalSettings.php
|
|
|
|
$wgNotificationReplyName = 'No Reply';
|
|
|
|
|
2013-04-09 22:13:39 +00:00
|
|
|
// Use the main db if this is set to false, to use a specific external db, just
|
|
|
|
// use any key defined in $wgExternalServers
|
|
|
|
$wgEchoCluster = false;
|
|
|
|
|
2015-10-26 15:27:31 +00:00
|
|
|
// Shared database to use for keeping track of cross-wiki unread notifications
|
|
|
|
// false to not keep track of it at all
|
|
|
|
$wgEchoSharedTrackingDB = false;
|
|
|
|
|
|
|
|
// Cluster the shared tracking database is located on, false if it is on the
|
|
|
|
// main one. Must be a key defined in $wgExternalServers
|
|
|
|
$wgEchoSharedTrackingCluster = false;
|
|
|
|
|
2016-05-29 20:54:15 +00:00
|
|
|
// Enable this when you've changed the section (alert vs message) of a notification
|
|
|
|
// type, but haven't yet finished running backfillUnreadWikis.php. This setting
|
|
|
|
// reduces performance but prevents glitchy and inaccurate information from being
|
|
|
|
// show to users while the unread_wikis table is being rebuilt.
|
|
|
|
$wgEchoSectionTransition = false;
|
|
|
|
|
|
|
|
// Enable this when you've changed the way bundled notifications are counted,
|
|
|
|
// but haven't yet finished running backfillUnreadWikis.php. Like $wgEchoSectionTransition,
|
|
|
|
// this setting reduces performance but prevents glitches.
|
|
|
|
$wgEchoBundleTransition = false;
|
|
|
|
|
2014-09-09 22:11:53 +00:00
|
|
|
// The max number of notifications allowed for a user to do a live update,
|
|
|
|
// this is also the number of max notifications allowed for a user to have
|
|
|
|
// @FIXME - the name is not intuitive, probably change it when the deleteJob patch
|
|
|
|
// is deployed to both deployment branches
|
2014-08-13 22:00:25 +00:00
|
|
|
$wgEchoMaxUpdateCount = 2000;
|
|
|
|
|
2013-03-06 00:04:48 +00:00
|
|
|
// The time interval between each bundle email in seconds
|
|
|
|
// set a small number for test wikis, should set this to 0 to disable email bundling
|
|
|
|
// if there is no delay queue support
|
|
|
|
$wgEchoBundleEmailInterval = 0;
|
|
|
|
|
2013-05-14 07:05:09 +00:00
|
|
|
// Whether or not to enable a new talk page message alert for logged in users
|
|
|
|
$wgEchoNewMsgAlert = true;
|
|
|
|
|
2016-03-18 00:00:05 +00:00
|
|
|
// Whether or not to show the footer feedback notice in the notifications popup
|
|
|
|
$wgEchoShowFooterNotice = false;
|
|
|
|
|
|
|
|
// A URL for the survey that appears in the footer feedback notice in the
|
|
|
|
// notification popup
|
|
|
|
$wgEchoFooterNoticeURL = '';
|
|
|
|
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
// Allowed notify types for all notifications and categories, unless overriden
|
|
|
|
// on a per-category or per-type basis.
|
|
|
|
// All of the keys from $wgEchoNotifiers must also be keys here.
|
|
|
|
$wgDefaultNotifyTypeAvailability = array(
|
|
|
|
'web' => true,
|
|
|
|
'email' => true,
|
|
|
|
);
|
|
|
|
|
|
|
|
// Define which notify types are available for each notification category
|
|
|
|
// If any notify types are omitted, it defaults to $wgDefaultNotifyTypeAvailability.
|
|
|
|
$wgNotifyTypeAvailabilityByCategory = array(
|
|
|
|
// Otherwise, a user->user email could trigger an additional redundant
|
|
|
|
// notification email.
|
2015-09-19 20:49:34 +00:00
|
|
|
'emailuser' => array(
|
|
|
|
'web' => true,
|
|
|
|
'email' => false,
|
|
|
|
),
|
2012-04-27 15:14:24 +00:00
|
|
|
);
|
|
|
|
|
2012-11-16 21:03:57 +00:00
|
|
|
// Definitions of the different types of notification delivery that are possible.
|
|
|
|
// Each definition consists of a class name and a function name.
|
|
|
|
// See also: EchoNotificationController class.
|
2012-04-27 15:14:24 +00:00
|
|
|
$wgEchoNotifiers = array(
|
2013-01-14 23:52:46 +00:00
|
|
|
'web' => array( 'EchoNotifier', 'notifyWithNotification' ), // web-based notification
|
2012-08-30 16:04:39 +00:00
|
|
|
'email' => array( 'EchoNotifier', 'notifyWithEmail' ),
|
2012-04-27 15:14:24 +00:00
|
|
|
);
|
|
|
|
|
2013-05-06 22:34:50 +00:00
|
|
|
// List of usernames that will not trigger notification creation. This is initially
|
|
|
|
// for bots that perform automated edits that are not important enough to regularly
|
|
|
|
// spam people with notifications. Set to empty array when not in use.
|
|
|
|
$wgEchoAgentBlacklist = array();
|
|
|
|
|
|
|
|
// Page location of community maintained blacklist within NS_MEDIAWIKI. Set to null to disable.
|
|
|
|
$wgEchoOnWikiBlacklist = 'Echo-blacklist';
|
|
|
|
|
|
|
|
// sprintf format of per-user notification agent whitelists. Set to null to disable.
|
|
|
|
$wgEchoPerUserWhitelistFormat = '%s/Echo-whitelist';
|
|
|
|
|
2016-05-13 20:48:03 +00:00
|
|
|
// Whether to enable the cross-wiki notifications feature. To enable this feature you need to:
|
|
|
|
// - have a global user system (e.g. CentralAuth or a shared user table)
|
|
|
|
// - have $wgMainStash and $wgMainWANCache shared between wikis
|
|
|
|
// - configure $wgEchoSharedTrackingDB
|
|
|
|
$wgEchoCrossWikiNotifications = false;
|
|
|
|
|
2015-11-30 23:14:57 +00:00
|
|
|
// Feature flag for the cross-wiki notifications beta feature
|
2016-03-11 01:48:06 +00:00
|
|
|
// If this is true, the cross-wiki notifications preference will appear in the BetaFeatures section;
|
|
|
|
// if this is false, it'll appear in the Notifications section instead.
|
|
|
|
// This does not control whether cross-wiki notifications are enabled by default. For that,
|
|
|
|
// use $wgDefaultUserOptions['echo-cross-wiki-notifications'] = true;
|
2015-11-30 23:14:57 +00:00
|
|
|
$wgEchoUseCrossWikiBetaFeature = false;
|
|
|
|
|
2013-02-16 02:20:34 +00:00
|
|
|
// Define the categories that notifications can belong to. Categories can be
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
// assigned the following parameters: priority, no-dismiss, tooltip, and usergroups.
|
|
|
|
|
2013-05-02 00:12:59 +00:00
|
|
|
// All parameters are optional.
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
|
2013-02-16 02:20:34 +00:00
|
|
|
// If a notifications type doesn't have a category parameter, it is
|
|
|
|
// automatically assigned to the 'other' category which is lowest priority and
|
|
|
|
// has no preferences or dismissibility.
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
|
2013-02-16 02:20:34 +00:00
|
|
|
// The priority parameter controls the order in which notifications are
|
|
|
|
// displayed in preferences and batch emails. Priority ranges from 1 to 10. If
|
|
|
|
// the priority is not specified, it defaults to 10, which is the lowest.
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
|
2013-01-17 00:31:56 +00:00
|
|
|
// The usergroups param specifies an array of usergroups eligible to recieve the
|
2013-02-16 02:20:34 +00:00
|
|
|
// notifications in the category. If no usergroups parameter is specified, all
|
|
|
|
// groups are eligible.
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
|
|
|
|
// The no-dismiss parameter disables the dismissability of notifications in the
|
|
|
|
// category. It can either be set to an array of notify types (see
|
|
|
|
// $wgEchoNotifiers) or an array containing 'all'. If no-dismiss is 'all',
|
|
|
|
// it will not appear in preferences.
|
2013-02-16 02:20:34 +00:00
|
|
|
$wgEchoNotificationCategories = array(
|
|
|
|
'system' => array(
|
|
|
|
'priority' => 9,
|
|
|
|
'no-dismiss' => array( 'all' ),
|
|
|
|
),
|
2013-10-25 02:25:42 +00:00
|
|
|
'user-rights' => array( // bug 55337
|
|
|
|
'priority' => 9,
|
|
|
|
'tooltip' => 'echo-pref-tooltip-user-rights',
|
|
|
|
),
|
2013-02-16 02:20:34 +00:00
|
|
|
'other' => array(
|
|
|
|
'no-dismiss' => array( 'all' ),
|
2013-01-14 23:52:46 +00:00
|
|
|
),
|
2012-11-27 01:53:35 +00:00
|
|
|
'edit-user-talk' => array(
|
2013-01-14 23:52:46 +00:00
|
|
|
'priority' => 1,
|
2013-02-16 02:20:34 +00:00
|
|
|
'no-dismiss' => array( 'web' ),
|
2013-05-02 00:12:59 +00:00
|
|
|
'tooltip' => 'echo-pref-tooltip-edit-user-talk',
|
2012-11-27 01:53:35 +00:00
|
|
|
),
|
|
|
|
'reverted' => array(
|
2012-10-28 16:47:41 +00:00
|
|
|
'priority' => 9,
|
2013-05-02 00:12:59 +00:00
|
|
|
'tooltip' => 'echo-pref-tooltip-reverted',
|
2012-11-27 01:53:35 +00:00
|
|
|
),
|
2012-12-26 22:05:29 +00:00
|
|
|
'article-linked' => array(
|
2012-10-28 16:47:41 +00:00
|
|
|
'priority' => 5,
|
2013-05-02 00:12:59 +00:00
|
|
|
'tooltip' => 'echo-pref-tooltip-article-linked',
|
2012-10-28 16:47:41 +00:00
|
|
|
),
|
|
|
|
'mention' => array(
|
|
|
|
'priority' => 4,
|
2013-05-02 00:12:59 +00:00
|
|
|
'tooltip' => 'echo-pref-tooltip-mention',
|
2012-12-26 22:05:29 +00:00
|
|
|
),
|
2015-09-19 20:49:34 +00:00
|
|
|
'emailuser' => array(
|
|
|
|
'priority' => 9,
|
|
|
|
'tooltip' => 'echo-pref-tooltip-emailuser',
|
|
|
|
),
|
2012-11-27 01:53:35 +00:00
|
|
|
);
|
|
|
|
|
2013-04-29 03:40:56 +00:00
|
|
|
$echoIconPath = "Echo/modules/icons";
|
|
|
|
|
|
|
|
// Defines icons, which are 30x30 images. This is passed to BeforeCreateEchoEvent so
|
|
|
|
// extensions can define their own icons with the same structure. It is recommended that
|
|
|
|
// extensions prefix their icon key. An example is myextension-name. This will help
|
|
|
|
// avoid namespace conflicts.
|
2015-10-29 11:23:31 +00:00
|
|
|
// * You can use either a path or a url, but not both.
|
|
|
|
// The value of 'path' is relative to $wgExtensionAssetsPath.
|
|
|
|
// * The value of 'url' should be a URL.
|
|
|
|
// * You should customize the site icon URL, which is:
|
|
|
|
// $wgEchoNotificationIcons['site']['url']
|
2013-04-29 03:40:56 +00:00
|
|
|
$wgEchoNotificationIcons = array(
|
|
|
|
'placeholder' => array(
|
|
|
|
'path' => "$echoIconPath/Generic.png",
|
|
|
|
),
|
|
|
|
'trash' => array(
|
2016-02-05 04:43:04 +00:00
|
|
|
'path' => "$echoIconPath/trash.svg",
|
2013-04-29 03:40:56 +00:00
|
|
|
),
|
|
|
|
'chat' => array(
|
2016-01-15 01:10:50 +00:00
|
|
|
'path' => "$echoIconPath/chat.svg",
|
2013-04-29 03:40:56 +00:00
|
|
|
),
|
2016-01-18 23:55:47 +00:00
|
|
|
'edit' => array(
|
|
|
|
'path' => array(
|
|
|
|
'ltr' => "$echoIconPath/ooui-edit-ltr-progressive.svg",
|
|
|
|
'rtl' => "$echoIconPath/ooui-edit-rtl-progressive.svg",
|
|
|
|
),
|
|
|
|
),
|
2016-01-13 04:24:11 +00:00
|
|
|
'edit-user-talk' => array(
|
|
|
|
'path' => "$echoIconPath/edit-user-talk.svg",
|
|
|
|
),
|
2013-04-29 03:40:56 +00:00
|
|
|
'linked' => array(
|
2015-12-17 17:29:38 +00:00
|
|
|
'path' => "$echoIconPath/link-blue.svg",
|
2013-04-29 03:40:56 +00:00
|
|
|
),
|
2016-01-13 04:24:11 +00:00
|
|
|
'mention' => array(
|
|
|
|
'path' => "$echoIconPath/mention.svg",
|
|
|
|
),
|
2013-04-29 03:40:56 +00:00
|
|
|
'reviewed' => array(
|
2016-01-15 01:26:23 +00:00
|
|
|
'path' => "$echoIconPath/reviewed.svg",
|
2013-04-29 03:40:56 +00:00
|
|
|
),
|
|
|
|
'revert' => array(
|
2015-12-17 17:29:38 +00:00
|
|
|
'path' => "$echoIconPath/revert.svg",
|
2013-04-29 03:40:56 +00:00
|
|
|
),
|
2016-01-13 04:24:11 +00:00
|
|
|
'user-rights' => array(
|
|
|
|
'path' => "$echoIconPath/user-rights.svg",
|
|
|
|
),
|
|
|
|
'emailuser' => array(
|
|
|
|
'path' => "$echoIconPath/emailuser.svg",
|
|
|
|
),
|
2016-01-15 22:19:01 +00:00
|
|
|
'global' => array(
|
|
|
|
'path' => "$echoIconPath/global.svg"
|
|
|
|
),
|
2013-04-29 03:40:56 +00:00
|
|
|
'site' => array(
|
|
|
|
'url' => false
|
|
|
|
),
|
|
|
|
);
|
|
|
|
|
2013-02-15 23:34:47 +00:00
|
|
|
// Definitions of the notification event types built into Echo.
|
|
|
|
// If formatter-class isn't specified, defaults to EchoBasicFormatter.
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
|
|
|
|
// 'notify-type-availabilty' - Defines which notifier (e.g. web/email) types are available
|
|
|
|
// for each notification type (e.g. welcome). Notification types are the keys of
|
|
|
|
// $wgEchoNotificationCategories.
|
|
|
|
|
|
|
|
// This is *ONLY* considered if the category is 'no-dismiss'. Otherwise,
|
|
|
|
// use $wgNotifyTypeAvailabilityByCategory
|
|
|
|
|
|
|
|
// Without this constraint, we would have no way to display this information
|
|
|
|
// on Special:Preferences in a non-misleading way.
|
|
|
|
|
|
|
|
// If any notify types are omitted, it defaults to $wgNotifyTypeAvailabilityByCategory
|
|
|
|
// which itself defaults to $wgDefaultNotifyTypeAvailability.
|
2013-02-16 02:20:34 +00:00
|
|
|
$wgEchoNotifications = array(
|
2013-01-14 23:52:46 +00:00
|
|
|
'welcome' => array(
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2014-07-31 02:31:47 +00:00
|
|
|
'EchoUserLocator::locateEventAgent'
|
|
|
|
),
|
2013-02-16 02:20:34 +00:00
|
|
|
'category' => 'system',
|
2013-04-30 22:28:50 +00:00
|
|
|
'group' => 'positive',
|
2016-06-10 12:51:45 +00:00
|
|
|
'section' => 'message',
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
// Only send web notification for welcome event
|
|
|
|
'notify-type-availability' => array(
|
|
|
|
'email' => false,
|
|
|
|
),
|
2015-11-03 00:00:29 +00:00
|
|
|
'presentation-model' => 'EchoWelcomePresentationModel',
|
2013-01-14 23:52:46 +00:00
|
|
|
'title-message' => 'notification-new-user',
|
|
|
|
'title-params' => array( 'agent' ),
|
2013-04-29 03:40:56 +00:00
|
|
|
'icon' => 'site',
|
2013-01-14 23:52:46 +00:00
|
|
|
),
|
2012-04-27 15:14:24 +00:00
|
|
|
'edit-user-talk' => array(
|
2015-11-17 13:37:39 +00:00
|
|
|
'presentation-model' => 'EchoEditUserTalkPresentationModel',
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2014-07-29 23:54:00 +00:00
|
|
|
'EchoUserLocator::locateTalkPageOwner',
|
|
|
|
),
|
2013-06-12 23:18:26 +00:00
|
|
|
'primary-link' => array( 'message' => 'notification-link-text-view-message', 'destination' => 'section' ),
|
|
|
|
'secondary-link' => array( 'message' => 'notification-link-text-view-changes', 'destination' => 'diff' ),
|
2013-02-16 02:20:34 +00:00
|
|
|
'category' => 'edit-user-talk',
|
|
|
|
'group' => 'interactive',
|
2016-06-10 12:51:45 +00:00
|
|
|
'section' => 'alert',
|
2013-01-15 23:21:39 +00:00
|
|
|
'bundle' => array( 'web' => true, 'email' => false ),
|
2013-07-24 03:50:43 +00:00
|
|
|
'formatter-class' => 'EchoEditUserTalkFormatter',
|
2013-01-07 22:44:58 +00:00
|
|
|
'title-message' => 'notification-edit-talk-page2',
|
2013-05-14 22:22:52 +00:00
|
|
|
'title-params' => array( 'agent', 'user', 'subject-anchor' ),
|
2013-01-15 23:21:39 +00:00
|
|
|
'bundle-message' => 'notification-edit-talk-page-bundle',
|
|
|
|
'bundle-params' => array( 'agent', 'user', 'agent-other-display', 'agent-other-count' ),
|
2013-01-07 22:44:58 +00:00
|
|
|
'email-subject-message' => 'notification-edit-talk-page-email-subject2',
|
2013-06-24 00:22:08 +00:00
|
|
|
'email-subject-params' => array( 'agent' ),
|
2013-01-07 22:44:58 +00:00
|
|
|
'email-body-batch-message' => 'notification-edit-talk-page-email-batch-body2',
|
2013-03-06 00:04:48 +00:00
|
|
|
'email-body-batch-params' => array( 'agent' ),
|
|
|
|
'email-body-batch-bundle-message' => 'notification-edit-user-talk-email-batch-bundle-body',
|
|
|
|
'email-body-batch-bundle-params' => array( 'agent', 'agent-other-display', 'agent-other-count' ),
|
2016-01-13 04:24:11 +00:00
|
|
|
'icon' => 'edit-user-talk',
|
2015-07-02 03:36:47 +00:00
|
|
|
'immediate' => true,
|
2012-04-27 15:14:24 +00:00
|
|
|
),
|
2012-07-18 19:39:33 +00:00
|
|
|
'reverted' => array(
|
2015-11-17 15:10:33 +00:00
|
|
|
'presentation-model' => 'EchoRevertedPresentationModel',
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2014-07-30 03:18:48 +00:00
|
|
|
array( 'EchoUserLocator::locateFromEventExtra', array( 'reverted-user-id' ) ),
|
2014-07-31 02:31:47 +00:00
|
|
|
),
|
2013-06-12 23:18:26 +00:00
|
|
|
'primary-link' => array( 'message' => 'notification-link-text-view-edit', 'destination' => 'diff' ),
|
2013-02-16 02:20:34 +00:00
|
|
|
'category' => 'reverted',
|
|
|
|
'group' => 'negative',
|
2014-08-05 21:50:54 +00:00
|
|
|
'section' => 'alert',
|
2013-02-15 23:34:47 +00:00
|
|
|
'formatter-class' => 'EchoEditFormatter',
|
2013-01-07 22:44:58 +00:00
|
|
|
'title-message' => 'notification-reverted2',
|
2015-09-17 22:59:57 +00:00
|
|
|
'title-params' => array( 'agent', 'title', 'difflink', 'number', 'userpage-contributions' ),
|
2013-01-07 22:44:58 +00:00
|
|
|
'email-subject-message' => 'notification-reverted-email-subject2',
|
2012-12-28 23:43:20 +00:00
|
|
|
'email-subject-params' => array( 'agent', 'title', 'number' ),
|
2013-01-07 22:44:58 +00:00
|
|
|
'email-body-batch-message' => 'notification-reverted-email-batch-body2',
|
2012-12-28 23:43:20 +00:00
|
|
|
'email-body-batch-params' => array( 'agent', 'title', 'number' ),
|
2012-07-18 19:39:33 +00:00
|
|
|
'icon' => 'revert',
|
2012-12-26 22:05:29 +00:00
|
|
|
),
|
2013-01-15 23:21:39 +00:00
|
|
|
'page-linked' => array(
|
2015-11-17 16:42:40 +00:00
|
|
|
'presentation-model' => 'EchoPageLinkedPresentationModel',
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2014-07-31 02:31:47 +00:00
|
|
|
'EchoUserLocator::locateArticleCreator',
|
|
|
|
),
|
2013-06-12 23:18:26 +00:00
|
|
|
'primary-link' => array( 'message' => 'notification-link-text-view-page', 'destination' => 'link-from-page' ),
|
2013-02-16 02:20:34 +00:00
|
|
|
'category' => 'article-linked',
|
2013-04-30 22:28:50 +00:00
|
|
|
'group' => 'neutral',
|
2016-06-10 12:51:45 +00:00
|
|
|
'section' => 'message',
|
2016-06-07 20:08:16 +00:00
|
|
|
'bundle' => array( 'web' => true, 'email' => true, 'expandable' => true ),
|
2013-01-15 23:21:39 +00:00
|
|
|
'formatter-class' => 'EchoPageLinkFormatter',
|
|
|
|
'title-message' => 'notification-page-linked',
|
|
|
|
'title-params' => array( 'agent', 'title', 'link-from-page' ),
|
|
|
|
'email-subject-message' => 'notification-page-linked-email-subject',
|
|
|
|
'email-subject-params' => array(),
|
|
|
|
'email-body-batch-message' => 'notification-page-linked-email-batch-body',
|
|
|
|
'email-body-batch-params' => array( 'agent', 'title', 'link-from-page' ),
|
2013-03-06 00:04:48 +00:00
|
|
|
'email-body-batch-bundle-message' => 'notification-page-linked-email-batch-bundle-body',
|
|
|
|
'email-body-batch-bundle-params' => array( 'agent', 'title', 'link-from-page', 'link-from-page-other-display', 'link-from-page-other-count' ),
|
2012-12-26 22:05:29 +00:00
|
|
|
'icon' => 'linked',
|
|
|
|
),
|
2012-10-28 16:47:41 +00:00
|
|
|
'mention' => array(
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2014-07-30 03:18:48 +00:00
|
|
|
array( 'EchoUserLocator::locateFromEventExtra', array( 'mentioned-users' ) ),
|
2014-07-31 02:31:47 +00:00
|
|
|
),
|
2013-06-12 23:18:26 +00:00
|
|
|
'primary-link' => array( 'message' => 'notification-link-text-view-mention', 'destination' => 'section' ),
|
|
|
|
'secondary-link' => array( 'message' => 'notification-link-text-view-changes', 'destination' => 'diff' ),
|
2013-02-16 02:20:34 +00:00
|
|
|
'category' => 'mention',
|
|
|
|
'group' => 'interactive',
|
2014-08-05 21:50:54 +00:00
|
|
|
'section' => 'alert',
|
2015-10-29 17:52:04 +00:00
|
|
|
'presentation-model' => 'EchoMentionPresentationModel',
|
2013-11-20 21:52:14 +00:00
|
|
|
'formatter-class' => 'EchoMentionFormatter',
|
2012-10-28 16:47:41 +00:00
|
|
|
'title-message' => 'notification-mention',
|
2015-12-04 21:41:41 +00:00
|
|
|
'title-params' => array( 'agent', 'subject-anchor', 'title', 'section-title', 'main-title-text', 'user' ),
|
2012-10-28 16:47:41 +00:00
|
|
|
'email-subject-message' => 'notification-mention-email-subject',
|
2015-12-04 21:41:41 +00:00
|
|
|
'email-subject-params' => array( 'agent', 'user' ),
|
2012-10-28 16:47:41 +00:00
|
|
|
'email-body-batch-message' => 'notification-mention-email-batch-body',
|
2015-12-04 21:41:41 +00:00
|
|
|
'email-body-batch-params' => array( 'agent', 'title', 'section-title', 'main-title-text', 'user' ),
|
2016-01-13 04:24:11 +00:00
|
|
|
'icon' => 'mention',
|
2013-03-13 00:49:19 +00:00
|
|
|
),
|
|
|
|
'user-rights' => array(
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2014-07-30 03:18:48 +00:00
|
|
|
array( 'EchoUserLocator::locateFromEventExtra', array( 'user' ) ),
|
2014-07-31 02:31:47 +00:00
|
|
|
),
|
2013-08-01 00:18:23 +00:00
|
|
|
'primary-link' => array( 'message' => 'echo-learn-more', 'destination' => 'user-rights-list' ),
|
2013-10-25 02:25:42 +00:00
|
|
|
'category' => 'user-rights',
|
2013-04-30 22:28:50 +00:00
|
|
|
'group' => 'neutral',
|
2014-08-05 21:50:54 +00:00
|
|
|
'section' => 'alert',
|
2015-08-19 20:22:45 +00:00
|
|
|
'presentation-model' => 'EchoUserRightsPresentationModel',
|
|
|
|
// Legacy formatting system
|
2013-03-13 00:49:19 +00:00
|
|
|
'formatter-class' => 'EchoUserRightsFormatter',
|
|
|
|
'title-message' => 'notification-user-rights',
|
|
|
|
'title-params' => array( 'agent', 'user-rights-list' ),
|
|
|
|
'email-subject-message' => 'notification-user-rights-email-subject',
|
|
|
|
'email-subject-params' => array(),
|
|
|
|
'email-body-batch-message' => 'notification-user-rights-email-batch-body',
|
|
|
|
'email-body-batch-params' => array( 'agent', 'user-rights-list' ),
|
2016-01-13 04:24:11 +00:00
|
|
|
'icon' => 'user-rights',
|
2013-03-13 00:49:19 +00:00
|
|
|
),
|
2015-09-19 20:49:34 +00:00
|
|
|
'emailuser' => array(
|
2015-11-17 17:44:45 +00:00
|
|
|
'presentation-model' => 'EchoEmailUserPresentationModel',
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2015-09-19 20:49:34 +00:00
|
|
|
array( 'EchoUserLocator::locateFromEventExtra', array( 'to-user-id' ) ),
|
|
|
|
),
|
|
|
|
'category' => 'emailuser',
|
|
|
|
'group' => 'neutral',
|
|
|
|
'section' => 'alert',
|
|
|
|
'title-message' => 'notification-emailuser',
|
|
|
|
'title-params' => array( 'agent' ),
|
2016-01-13 04:24:11 +00:00
|
|
|
'icon' => 'emailuser',
|
2015-09-19 20:49:34 +00:00
|
|
|
),
|
2015-11-25 04:07:54 +00:00
|
|
|
'foreign' => array(
|
|
|
|
'presentation-model' => 'EchoForeignPresentationModel',
|
Allow certain users to be excluded
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
2016-02-02 13:16:39 +00:00
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array(
|
2015-11-25 04:07:54 +00:00
|
|
|
'EchoUserLocator::locateEventAgent'
|
|
|
|
),
|
|
|
|
'category' => 'foreign',
|
|
|
|
'group' => 'positive',
|
|
|
|
'section' => 'alert',
|
2016-01-15 22:19:01 +00:00
|
|
|
'icon' => 'global',
|
2015-11-25 04:07:54 +00:00
|
|
|
),
|
2016-01-18 23:55:47 +00:00
|
|
|
'thank-you-edit' => array(
|
|
|
|
'user-locators' => array(
|
|
|
|
'EchoUserLocator::locateEventAgent'
|
|
|
|
),
|
|
|
|
'category' => 'system',
|
BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-19 02:54:15 +00:00
|
|
|
// Only send 'web' notification
|
|
|
|
'notify-type-availability' => array(
|
|
|
|
'email' => false,
|
|
|
|
),
|
2016-01-18 23:55:47 +00:00
|
|
|
'group' => 'positive',
|
|
|
|
'presentation-model' => 'EchoEditThresholdPresentationModel',
|
2016-06-10 12:51:45 +00:00
|
|
|
'section' => 'message',
|
2016-01-18 23:55:47 +00:00
|
|
|
'icon' => 'edit',
|
|
|
|
),
|
2012-06-08 05:33:25 +00:00
|
|
|
);
|
2013-01-17 23:06:40 +00:00
|
|
|
|
2013-05-14 07:05:09 +00:00
|
|
|
// Enable new talk page messages alert for all logged in users by default
|
|
|
|
$wgDefaultUserOptions['echo-show-alert'] = true;
|
|
|
|
|
2013-01-17 23:06:40 +00:00
|
|
|
// By default, send emails for each notification as they come in
|
2013-10-23 19:31:35 +00:00
|
|
|
$wgDefaultUserOptions['echo-email-frequency'] = 0; /*EchoHooks::EMAIL_IMMEDIATELY*/
|
2013-01-17 23:06:40 +00:00
|
|
|
|
2016-04-26 01:33:01 +00:00
|
|
|
// By default, do not dismiss the beta feature invitation
|
|
|
|
$wgDefaultUserOptions['echo-dismiss-beta-invitation' ] = 0;
|
2016-03-18 00:00:05 +00:00
|
|
|
|
2013-06-24 00:22:08 +00:00
|
|
|
if ( $wgAllowHTMLEmail ) {
|
2013-10-23 19:31:35 +00:00
|
|
|
$wgDefaultUserOptions['echo-email-format'] = 'html'; /*EchoHooks::EMAIL_FORMAT_HTML*/
|
2013-06-24 00:22:08 +00:00
|
|
|
} else {
|
2013-10-23 19:31:35 +00:00
|
|
|
$wgDefaultUserOptions['echo-email-format'] = 'plain-text'; /*EchoHooks::EMAIL_FORMAT_PLAIN_TEXT*/
|
2013-06-24 00:22:08 +00:00
|
|
|
}
|
|
|
|
|
2013-04-25 00:41:47 +00:00
|
|
|
// Set all of the events to notify by web but not email by default (won't affect events that don't email)
|
2013-03-06 19:56:23 +00:00
|
|
|
foreach ( $wgEchoNotificationCategories as $category => $categoryData ) {
|
2013-04-25 00:41:47 +00:00
|
|
|
$wgDefaultUserOptions["echo-subscriptions-email-{$category}"] = false;
|
|
|
|
$wgDefaultUserOptions["echo-subscriptions-web-{$category}"] = true;
|
2013-01-17 23:06:40 +00:00
|
|
|
}
|
2013-01-15 23:21:39 +00:00
|
|
|
|
2013-04-27 01:39:11 +00:00
|
|
|
// most settings default to web on, email off, but override these
|
|
|
|
$wgDefaultUserOptions['echo-subscriptions-email-system'] = true;
|
2013-10-25 02:25:42 +00:00
|
|
|
$wgDefaultUserOptions['echo-subscriptions-email-user-rights'] = true;
|
2013-04-25 00:41:47 +00:00
|
|
|
$wgDefaultUserOptions['echo-subscriptions-web-article-linked'] = false;
|
2013-03-01 00:26:59 +00:00
|
|
|
|
2013-02-16 02:20:34 +00:00
|
|
|
// Echo Configuration for EventLogging
|
2013-03-01 00:26:59 +00:00
|
|
|
$wgEchoConfig = array(
|
2016-06-28 21:49:15 +00:00
|
|
|
'version' => '1.10',
|
2015-10-01 13:48:52 +00:00
|
|
|
'eventlogging' => array(
|
2015-07-08 19:29:00 +00:00
|
|
|
/**
|
|
|
|
* Properties:
|
|
|
|
* - 'enabled': Whether it should be used
|
|
|
|
* - 'revision': revision id of the schema
|
|
|
|
* - 'client': whether the schema is needed client-side
|
|
|
|
*/
|
2015-10-01 13:48:52 +00:00
|
|
|
'Echo' => array(
|
2013-03-06 19:56:23 +00:00
|
|
|
'enabled' => false,
|
2015-12-09 07:02:09 +00:00
|
|
|
'revision' => 7731316,
|
2015-07-08 19:29:00 +00:00
|
|
|
'client' => false,
|
2013-05-07 23:27:46 +00:00
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'EchoMail' => array(
|
2013-05-07 23:27:46 +00:00
|
|
|
'enabled' => false,
|
2015-07-08 19:29:00 +00:00
|
|
|
'revision' => 5467650,
|
|
|
|
'client' => false,
|
2013-05-07 23:27:46 +00:00
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'EchoInteraction' => array(
|
2013-06-05 20:44:06 +00:00
|
|
|
'enabled' => false,
|
2015-12-23 17:41:48 +00:00
|
|
|
'revision' => 15180901,
|
2015-07-08 19:29:00 +00:00
|
|
|
'client' => true,
|
2013-06-05 20:44:06 +00:00
|
|
|
),
|
2013-03-01 00:26:59 +00:00
|
|
|
)
|
|
|
|
);
|