When an user sent an email to another user with [[Special:Emailuser]] or
action=emailuser, give an echo for the target user to be lookup in his
mailbox.
This option is off by default. It is only useful as web notification,
because an email notification would go to the same address.
Bug: T56130
Change-Id: Ie279457daf51e1c34c998197ce9e76c78ee705e4
This changes the revert notification (special page version) to link
to the contributions page for anonymous (logged out) editors.
It still links to the user page for logged in editors.
Bug: T55564
Change-Id: Ib1f17fb88237b96cda63dd30ed488a8ffd84750e
Also:
* Clear the newtalk flag when they mark all their edit-user-talk
read.
* Remove the section caching system. It was designed to avoid
performance problems with Flow messages, but now that standard talk pages
are in 'messages', messages should be relatively common (alerts
were already not cached by this).
* Minor cleanups to reflect that messages are not only Flow (and
a typo fix in the Gruntfile).
Bug: T108760
Change-Id: I82d7b1d08331693830d6a1749612b55e96b95cf9
This preference has been disabled since bug 47562, and doesn't make
sense to keep around given that the flyout is the main interaction most
users have with Echo.
Change-Id: I7e8ddf96dbde9a95ac01a0cc83bad396151d01bd
Rather than making each notification type opt-in to using the job queue,
make them opt-out by setting an 'immediate' => true flag.
Configure the 'edit-user-talk' notification type to be immediate since
it should not lag behind the orange bar indicator.
Change-Id: I707bc01a97082887c3f1c353d45cdf1c1eaeff04
* Use standard "on{hook}" naming pattern
* Skip hook if using an external database server ($wgEchoCluster)
* Don't return true, it's not necessary anymore
Change-Id: I488e4636f9499c468b870966614b0762c2ade8ea
The Echo cohort study was finished in July 2013 and hasn't been used
since. The code was also checking in reverse order, for example it
checked registration before checking whether the survey was still
active.
EchoHooks::isEchoDisabled() was removed, and all callers were checked to
make sure they were also checking for anonymity.
EchoNotificationController::doNotification() will throw an exception if
the user is anonymous, since it shouldn't be possible to get an
anonymous user into that code path.
Bug: T101047
Change-Id: Iada2f6d2066c0f6bba5cc58aeb03d687632ac5a4
All uses of $wgEchoBackendName were hardcoded to 'Db' and removed.
This exposed a interesting bug in MWEchoEmailBundler which was
instantiating a subclass using the parent class's private constructor, a
"feature" of PHP which is supported in 5.2.6+ (http://3v4l.org/h4Mq3).
While it worked, PHPStorm complained about it so I made the constructor
protected, which makes more sense anyways.
Both EmailBatch and EmailBundler need further refactoring, but that will
be done in follow up patches.
Change-Id: I2032f5b2f4f3a62f830cc5344b25a92074bd0c61
Let EventLogging register the schema modules by using the
EventLoggingRegisterSchemas hook.
Don't modify $wgResourceModules at run time because that's a hack.
Instead register the module in the ResourceLoaderRegisterModules hook
itself.
Change-Id: I9457546c1ec38cf6896fe6f9f445fe1191afe72a
I tried to stick as close to the existing code as possible.
Special:Notifications is slightly different from the overlay,
however. I made it add .mw-echo-unread class for consistency,
but that JS doesn't record seen time (it only loads older
entries), not does the CSS fadeout apply there (it marks
everything as read as soon as it's displayed, so different
behavior from overlay)
PS: I'm not sure about browser compat for the fadeout. But
even if some obscure browsers don't support this, meh. It's
not an "important" feature that can't be missed.
Bug: T94634
Change-Id: Ibb201823fb52ef8a3d5eaa39b0b724ede8d271d1
The only issue is that the badge is not up to date till
you refresh the page, I think that's fine for now
Change-Id: I585b4cc185bf859ddb06829df75309ff3d56d8b8
* Moved most of the content from notify to getEventNotifyTypes
* Added phpunit test verifying per-event config overrides defaults
* Remove special-snowflake welcome handling with proper configuration
Change-Id: Ic1aae11d37f23f2b7b8abe3c1edaa414e29be021
Core titleCache doesn't do what I expect it to do, issuing
Title::newFromId( 1 ) mulitple times would issue multiple
idential queries to the database. It doesn't return what's
already in the cache.
The goal of this patch is to batch load titles via newFromIDs,
and save the number of mysql queries
Change-Id: I8fe767ac2669e67bdf7d17eecccfc0dcb6b5fc7d
The new locateUsersWatchingTitle implementation could end up returning
thousands of users, currently on enwiki there are 25 titles with more
than 10k subscribed users and aprox 550 titles with more than 1k subscribed
users.
This switches the user collection to an iterator based implementation so that
we no longer need to have the entire users list at any one time.
Change-Id: I3d3fa9328f348bb48682d3658622952ce82d3925
This will be used for marking a notificaiton as read when
a user visits a target page. The new table should keep the
volume as low as possible for fast data loopup. records
should be removed from the table once it's marked as read.
Change-Id: I605cbc79adfc12d22bd889c5bb513d05c479fe6e
* Shared function can be put in the abstract class and this also enforces some interface methods
* Initialize a default dbFactory when it's not passed to the mapper
Change-Id: I1033dafaa90a1f683fbe9ad69bed04f4844e357b
Replace implementation specific code with generalized user-locator
implementations that can be re-used by more notifications in other
extensions.
This patch adjusts the `user-locators` notification parameter to allow
arrays which facilitate passing options to the locator.
Previously(still works):
'user-locators' => array( 'foo', 'bar' ),
New functionality:
'user-locators' => array(
'foo',
array( 'bar', 42 )
)
In the second example the callback specified by `bar` will receive
an EchoEvent as the first argument and array( 42 ) as its second
argument.
Change-Id: I7305279bc91d1e40e7054e2fd42a819a35526b82
There are a variety of generic strategies you could define to choose
which users should be notified about an event, such as 'users watching
the title' or 'talk page owner' (User_talk only).
This adds a new way to generically implement these in Echo and expose them
to other extensions rather than having each extension implement these
generic strategies themselves.
This patch only converts one notification, edit-user-talk. The remaining
notifications will be converted in future patches. The first user of this
will be Flow for notifying all users watching a particular talk page in
I4e46a9c003fbdde274b20ac7aef8455eab4a5222
The users watching title implementation provided here is minimalist, a larger
refactor to accomidate pages with thousands of watchers is being handled
in I3d3fa9328f348bb48682d3658622952ce82d3925
Change-Id: I19bb6a794d22565f3bb5421de92426d390197796
* Get rid of EchoBackend by separating responsibilities into smaller objects
* Move main fetchNotification logic from API to a more appropriate place
* Add more unit testing coverage
Change-Id: I42f4d7566543332588431c21c220c0d64d026b70
Otherwise, it explodes when trying to run tests via PHPUnit:
Error: 1146 Table 'osmiumwiki.parsertest_echo_notification' doesn't exist (localhost)
Change-Id: I8a3e0171ab022e8e2973ea8bed9aacba73a35f34
