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
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
Since we didn't use to save seen time, it is unreliable at first.
I decided to just show them as read then, since we couldn't know
if they had or hadn't been read.
However, it would make more sense to keep them unread until we first
save the time a notifiation is seen: it is in line with the current
behavior (where the badge just stays red, always)
Also fixed a problem where I meant to .get a value but had .set
instead. It wasn't noticable because that function is currently
only called when things have just been seen, so even though it
was wrong, it produced a good result.
Bug: T94634
Change-Id: I7ee447249527feb3914c76cfffd673bbda062b75
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
Follows-up 8d12ef9.
Tests were failing because wgEchoConfig was undefined and ext.base.js
accesses wgEchoConfig.eventlogging.
This mock should not be needed. Modules should be loadable at any
time and react to the current environment. If they should not do
anything, the client should be able to determine that. Perhaps
an isAnon() or some property wgEchoConfig to indicate this.
It only being loaded from beforePageDisplay() when logged-in is a
load optimisation, not business logic. wgEchoConfig should always
be there, or the code should handle the case of it not being there.
Change-Id: Ide90adf20e583921c9f3bd5cd37057995aa3d2c3
This was supposed to merge master into the two_tabs branch, but it was accidently done against master instead
This reverts commit 06ee936e92.
Change-Id: I98da735b7d5c103399a2478286d1420243df6ba4
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
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
While running php phpunit.php --tap --testsuite extensions
in vagrant the unit tests for the echo extension were
not added to the file list.
See also
Bug: 67148
Change-Id: Id78580b4c13bbc3428727c23f1fe3e493ec127ec
Otherwise, it explodes when trying to run tests via PHPUnit:
Error: 1146 Table 'osmiumwiki.parsertest_echo_notification' doesn't exist (localhost)
Change-Id: I8a3e0171ab022e8e2973ea8bed9aacba73a35f34
General code cleanup as reported by the PHPStorm static code
analysis. I hope it's not a problem that I made a lot of very
different (but all very tiny) changes in a single patch. If you
want to merge this but you think it's better to split it into
several patches first, please tell me.
Change-Id: I2e2c4bb47f8d20e038d28e236e2ff813b30504af
If a user is watching his/her own talk, an edit to the talk page
may trigger an echo notification and watchlist notification. We
only want to send one of them
Depends on core patch: https://gerrit.wikimedia.org/r/#/c/114682/
Bug: 53569
Change-Id: Ib1bb71e047789d3a857f028aaa45384022bb35c7
Fallback to 'emailsender' message if not set
Change-Id: Id136692b80b7582a515501672259394e8db74112
Follows-Up: Id20e4ec1cdae94fadb278146cd72d5a9b247dccf
To test the HTML email:
1. install the latest version of php-mail and php-mail-mime package, they are required
by the core sendmail function to send HTML email
2. set $wgAllowHTMLEmail = true before loading Echo in LocalSetting.php
Change-Id: Ia4b98b14e135742b84f1b0e04589b0efdd24e954
wgUserNewMsgRevisionId is null with only one revision and that revision is
not viewed, this makes it not reliable for determining if there is new
message. We just switch to check against $user->getNewtalk() instead.
We can still use wgUserNewMsgRevisionId to generate diff links if desired
Change-Id: I4cf50a944aada03151bd17f3610bd59b3bfb2bf2
Echo preference change is already captured in the general
preference change eventlogging, this is just a duplicate
Change-Id: I49cd2ad5776a670e2cd28414e156f5201087ded0
SQLite requires unique index names across the full database. A previous
patch I9b6468221ba6fe501b15c563f3301694262eec65 renamed the index in
echo.sql but forgot to apply the same change to existing databases. This
resolves that mistake.
Change-Id: Ibb629149afd9f4ca55cac613124fce42500aa8f9
Sqlite's lack of an 'ALTER TABLE CHANGE' statement has prevented echo from
supporting sqlite, and by relation has prevented Echo's unit tests from
running within the foundations jenkins CI environment. This patch detects
if the database is currently an sqlite database and applies a specially
formulated patch that performs a rename/copy/delete operation to get
the equivilient of an 'ALTER TABLE CHANGE' command. Additionally renames
one index to have a more unique echo-specific name.
Bug: 41987
Change-Id: I9b6468221ba6fe501b15c563f3301694262eec65
Provides the first step of adding and populating a new database field
for Echo oversight deployment. The new field is populated via a
maintenance script and Event::loadFromRow will accept both new and old
results. Everything will still run when the 2 now unused fields are
later dropped from the db.
Bug: 48059
Change-Id: I24d4b61a061f94ed9aaaa6087f33b2ab37f773cd
With this change we will no longer be relying on JS for the badge
functionality. This will prevent the flash of unstyled content,
and allow wikis to locally override the styling (since the unread
class is now applied immediately).
I also went ahead and made the badge styling more closely match the
talk page message alert styling per Vibha.
Also removed the old full link optional behavior since we weren't
using it, and it would have been a pain to maintain.
Bug: 48165
Bug: 48001
Change-Id: Ie85d66afd5181d487d0bb2776ae14b121ea50d88
If we add an explicit prefix (similar to what the Gadgets extension
does), we won't have to have a special handler for checkmatrix options
in Preferences::filterDataForSubmit().
Depends on core change I4049b666
Change-Id: Ic8420b896bc013840eb3a32420a49f6719f30610
Instead of introducing a brand new option for this notification, we just
use the existing enotifusertalkpages
Change-Id: Ia63c9b1f4f52007004fa2860115b675aae4872fa
Updates usage of HTMLCheckMatrix to match recent refactor allowing
options to be forced on or off. Instead of hiding unavailable
checkboxes now we show them greyed out and unchangable. Depends on
https://gerrit.wikimedia.org/r/#/c/61163/ in core.
Bug: 47743
Change-Id: I9284a2ad29de654062e54a78a76c10dd49c35ed7
This patch makes Echo talk page notification mimic the existing Orange Bar and Email talk page notification
for minor edit.
For the Orange Bar, minor edit notification is sent if the editor does not have nominornewtalk
permission.
There are additional rules for the email, minor edit notification is sent if global $wgEnotifMinorEdit
is true and notification recipient has enotifminoredits option on.
Change-Id: Ib3835c4dd57a3686b227c44710a14ab06cded166
Previously Echo prevented all user_newtalk data from being generated
for logged in users. This broke the hasmsg API and also prevented
anyone from being able to implement client-side growlers or alerts
based on this data. The new approach is more conservative - it allows
updates to the user_newtalk table, but prevents the alert itself
(orange bar of doom) from being displayed to logged in users. This
will provide more flexibility for future development regarding talk
page alerts (both for extensions and gadgets).
Note: This change is dependant on the new core change I2105bdd2.
Bug: 47962
Change-Id: I3f35a56b3f1795c2b21a6e4af8fc93b5e61b7d3c
Also registering UserLoadOptions hook (oops!)
Finally, getting rid of old override system that is now obsolete.
Change-Id: Ie264981eb20f1e3d3c83721bc376d79e2f5a1430
Catches people who have opted out of old style talk page notifications and opts them out
of equivalent new ones.
Needs $wgRecentEchoInstall = true in LocalSettings.php so it can be turned off when no
longer needed.
The migration has 1 million rows to write on enwiki so will take some time
Change-Id: Ie6201df378bf8df813b3d461ea9a8521d99b1bb9
* Icon can be defined using a path or a URL
* Extensions don't need custom CSS, but add icon through BeforeCreateEchoEvent
* Sites set their notification icon in LocalSettings.php or equivalent
Bug: 46585
Change-Id: Ifc02b653d07de19229dfb2604305e32f3bd595fe
If we're using Echo to handle user talk page post notifications,
hide the old (non-Echo) preference for this. If Echo is moved to core
we'll want to remove this old user option entirely. For now, though,
we need to keep it defined in case Echo is ever uninstalled.
Otherwise, that preference could be lost entirely. This hiding logic
is not abstracted since there is only a single preference in core
that is potentially made obsolete by Echo.
Change-Id: I6c8b2143a5fd719486f7e6cbaa3d7635f507ffca
Default settings for existing users are intended to be low volume and not annoying
New users need more encouragement and incentive to return
Change-Id: Id37ad8289a5c968ae8be6a8c424a19d6cbc7e071
