Generally applicable, but intended for users affected by the
login-success phantom notifications bug.
Bug: T220762
Change-Id: Ica428bfc19e0555564ca04d80ac5009197401aaf
This was attempted in I6f87797701, but didn't work. The reason is that
notify-type-availability can't be set on a per-notiifcation basis for
visible categories, only for hidden categories. For visible categories,
it has to be set at the category level.
Bug: T219444
Change-Id: I6b6dd1ae6be549de0f6026841966f87527dd2365
This trait was using private fields from its host classes
($this->event, $this->language). It created a weird coupling
situation where the host class uses the trait and the trait
uses the host class. Effectively a circular dependency.
Also, phan is complaining about it in
I65ae6adc10941c05a2646e551b1baa829e4e8654
Change-Id: Ib2796b7ca62ecd7ece19583d7ca83e4252a5d878
This boilerplate at the beginning of most files is an anti-pattern from
very early 2011 frontend experiments (I take full blame), where I didn't
understand (or had confidence in) the load order of scripts. I won't
remove it all at once, as that requires careful review of dependencies.
But this one file seemed like low-hanging fruit. The "ext.echo.dm"
contained a file that lazy-created `mw.echo` as empty as empty object,
and `mw.echo.config` as `{ maxPrioritizedActions: 2 }`.
The "ext.echo.init" module loaded on every page already does the same.
Remove this file and depend on that module instead. The same modules
will be downloaded, in the same way, and in the same order as before.
What changes is that the order of execution is now defined instead of
implied, thus making the dm-version of it redundant.
In practice, while fragile, the load order was already consistently
running init before dm. I found this through code coverage analysis in
Chrome DevTools, <https://phabricator.wikimedia.org/F28421786>.
Change-Id: Iaed7cf0e47479ce8ce76aee1bfe479d82b4f61ed
This is not used anywhere else and doesn't appear to be something
that is intended to be usable or loadable as its own entry point.
The name 'ext.echo.ui' could be improved to better reflect the
bundle purpose it represents, but thats a breaking change for a
separate commit at the discretion of the maintainers' preferences.
Change-Id: If9cf287917a51de96a36d534b7c0cfadf1accf9a
No longer used in the new bundling system.
Also removes indexes that contain bundle_base.
Bug: T143763
Bug: T131415
Change-Id: Ibf94cdc471a11cb14995fee6a55af0d227b50aa5
Specify which notification types allow notifying the event agent in
$wgEchoNotifications, and stop specifying it in the event_extra data.
Putting 'notifyAgent' => true in event_extra will still work, but is
discouraged.
Change-Id: I4f558654ec23757dd4ecd6986eb3e9a5593f5386
That way we'll be able to mix it into non-query modules as well.
Unfortunately, PHP traits don't let overridden methods call their
original versions, which had to be worked around in a few places:
- $this->foreignNotifications can't be initialized in the constructor
any more, so it's now lazy-created through $this->getForeignNotifications()
- Adding the 'wikis' parameter to getAllowedParams() now happens by
calling getCrossWikiParams() rather than calling the parent
- Overriding getForeignQueryParams() can't call the parent anymore, so
instead we just inline it
Change-Id: I415e6d921819fc1f7869c7d2f8bb62830a84c2a1
This is what MediaWiki itself does. It's not great, and isn't any more
translatable than a config setting, but consistency isn't valueless. In
future, with T202326 we may wish to vary this, but for now this is
simpler.
Change-Id: I76fca8ee255c65ab9b7e988d44de0d0fbd3c84b7
Instead just use the system message `emailsender` like we do for all other
e-mails, which is thus translatable.
Change-Id: I7e58a3a4e224d551c6fae4a76fcba19fe838d3e9
Instead just use $wgPasswordSender explicitly. This also allows us to drop the
extension registration callback function, which is a performance improvement.
Bug: T200390
Change-Id: I08d2f040c5ad8feb395a2e8e176f91636efe1d3d
* Move revision ids out of configuration and into MWEchoEventLogging
class. Because the EchoInteraction schema is used both server and
client, we have to duplicate the revision id.
* Use EventLoggingSchemas attribute to register client-side schema in
extension.json instead of a hook.
* Check if EventLogging is enabled in MWEchoEventLogging instead of
$wgExtensionFunctions.
* Pass only whether the EchoInteraction schema is enabled to the
client-side instead of all of $wgEchoEventLoggingSchemas.
Change-Id: I968294f96cedac19dc9d8f53df14fecfb666ceee
$wgExtensionFunctions are run on every MediaWiki request, and should be
avoided unless necessary. Default user options should be controlled by
the UserGetDefaultOptions hook instead.
Bug: T180192
Change-Id: I2a79e078753d289c3ea2f04b613ce72c59a9e59a
Can be removed now that it's been moved to PageTriage.
This reverts commit b59eedd251.
Change-Id: If829148d09cb28f21bd48d5073886b44174b274d
Depends-On: I370391d7460c5b04a5a1ddb2e191f29044b30e5e
Still being used by PageTriage.
The proper solution is to move the icon to PageTriage, but
for now let's bring it back in Echo to unbreak things.
This reverts commit 54f49875e9.
Bug: T191335
Change-Id: If4c709d9932ac0d063f6211c5ddd82846f0f6a6d
* Rename to match their upstream names.
* For icons without upstream versions, fix canvas to 20x20.
* Use consistent suffices to indicator colour.
Change-Id: Ie6252a8ccbba79143a0f77536c6470b4350be1ad
All files containing more than one PHP class were split into
multiple files.
extension.json was updated to match new class locations.
phpcs `OneObjectStructurePerFile.MultipleFound` rule was
re-enabled.
Bug: T177809
Change-Id: I6fc2ec9cc35e6bac5a7c44d94b0f1b1b40e6dba5
All files containing more than one PHP class were split into
multiple files.
extension.json was updated to match new class locations.
Bug: T177809
Change-Id: I4e7d8f02164c3048c41c4c9fbe4be18a99e7abaa
The echo mute list uses user names which are not stable. User ids should be used instead.
Bug: T173475
Change-Id: I947bcf37a8f85aaa105776d368dbd0ab76823aeb
This will be used to submit a new article reminder, for a specified date.
The delay is not implemented yet.
Bug: T166973
Bug: T167450
Change-Id: I773bbe98e781957912350c481c850b3263cb1821
Includes feature flag, presentation model.
Temporarly hooks to new user creation.
Bug: T165755
Bug: T165754
Change-Id: Ic0a2ca07b0cd1597e5534bb1f3b748beb215ddfc
Just show the textual "Alerts (1)" and "Notices (1)".
Updated NotificationBadgeWidget to use that internally as label,
same as the PHP-generated list item does after d4d325e7.
Bug: T141944
Change-Id: I468c67b0866530e21c9af32cd02816075a3693a1
* The JSON file for the Apex theme was exactly identical to the
MediaWiki theme. If the icons are the same, there's no need to
duplicate it.
* Since we now only have one definition used for all themes,
ResourceLoaderOOUIImageModule is overkill and we can use the
slightly simpler ResourceLoaderImageModule.
* Remove "prefix": "oo-ui-icon" from the JSON file, since it is
overridden in the module definition by "selectorWithoutVariant" and
"selectorWithVariant".
Change-Id: I1d579873459e079369fd13350a9cb00939c2b76b
This time we actually get to *remove* a hack that overrides OOUI,
which is always nice. Also add our new dependency on future-magic
forthcoming MediaWiki version.
Change-Id: Icef086e6b19dffb34eefe7b5658b57e020c5de8b
Before, secondary icons, such as linked, changes, thanks, and
userSpeechBubble were loaded in mw.echo.ui.icons.less. Now, an
extra icons attribute is passed when the module is loaded, allowing
RLEIM to know which icons to load. If this attribute is left out,
an MWException will be thrown.
Bug: T159394
Change-Id: I9b36a74bcf1da0d1c698845bd067b226fb81ac96
There are many API messages in Echo, so to make it easier
for translators, they are now in a separate group.
This is similar in Flow.
Must be merged along with the translatewiki change at
Iecedfe4cb9dc8e62a446a3e1c415a79e116ca27e
Change-Id: I1d3baea708107a7f15bf19671f7386eaf7e33a1b
When generating extension.json, I missed the fact that
this module has a dynamic localBasePath (set to $wgExtensionDirectory),
and this turned into "localBasePath": null.
Instead, register this module dynamically.
Bug: T153261
Change-Id: I61709d6ea0948dd983ab41c9457adda434525bb7
