Adds statsd counters for events and notifications, both overall and by
type. (Events and notifications have a one-to-many relationship, as
notifications may be created for multiple users per event.)
These are specifically of interest to estimate the potential volume of
notifications to be handled by the new push service.
Bug: T260836
Change-Id: I41974cd30a90c674f56003e15d540a5581d19c7d
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Usage.ForbiddenFunctions.isset
* MediaWiki.Usage.PHPUnitDeprecatedMethods.AssertInternalTypeGeneric
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
Change-Id: I29416247ff3736799543926813beaf4afd569a6e
To my knowledge in all the places I'm touching in this patch the new
code is functionally identical to the old one.
Change-Id: I0ffa96d2f9cb9bf932f68b689244051c96c17ad9
Class Revision is deprecated and in this patch, replaces
usage with appropriate classes; RevisionRecord, RevisionStore,
etc.
Bug: T221163
Change-Id: Icfc85167a636bef95daab236ab80113c1a3cf41b
When pages are deleted or undeleted, their associated
Echo notifications also need to be marked as deleted
or undeleted. This is done by looking up the
echo_target_page table.
With this change, echo_event.event_page_id is also included
in the search. This way, all the events that don't use
target pages are also moderated when needed.
Bug: T217452
Change-Id: I277fca68ce088ab564e76ed9dfb2134ab3be4c4a
By running updateEchoSchemaForSuppression.php as an updater.
The patch-*.sql files already existed, they were added
in 2013(!) by 34fbeaf8c but never applied.
Bug: T136427
Bug: T50059
Change-Id: Ied049681df4bab325f069c3a68cf704ee9a8f2c9
This fixes tests, because EchoHooks has "echo_event.*" which is invalid
with table prefixes, like done in unit tests
Added EchoEvent::selectFields() for future use and to replace more
SELECT *
Bug: T217487
Change-Id: I51cb46812431635d11780633dc7d807cd04f813d
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
This fixes some issues I found while updating this code base, e.g.
this removes types a method really does not return.
Change-Id: I19457e7bf88945eec958bf53e0b76a7585715a45
Most modern IDEs as well as documentation generators understand the
keywords "false" and "true", when a bool can only be one of the two.
Change-Id: I83dd1f0cc0802fa74ee35e7ca7425615230a767f
Add the ability to create notifications with specific timestamps
when generating notifications through the maintenance script.
Note, that not all notifications can be given specific timestamp;
only notifications that do not involve a direct editing action
will be given this timestamp and their events will be created
as if the actions were taken at the given timestamp, with
1 minute intervals.
Change-Id: I9e6b8660178ca0734979946c8e6ec8d43fc3de41
Doing it in two lines makes it easier to read
This makes also clear that this is not a broken condition
Change-Id: I9771b6457789b7dc572f2d73d1fae8c361f9a1e6
User objects haven't been stubbed in awhile, and language objects
aren't being stubbed anymore.
While we're here, swap a few MWException -> InvalidArgumentException
since they're more accurate :)
Change-Id: I7e2f2aa135b024fb653c3ec13181d7015383ff2f
Target page entries used to exist for each user
that was notified for an event. They were
removed as the notifications were marked as read.
Now they remain so that the association between
pages and events can be used for moderation
regardless of the notifications read status.
This patch removes everything about
echo_target_page.etp_user from sql and php code.
Bug: T143959
Change-Id: Ib57510e6b0e9202a7e035f8ea59955dca8a0b24a
* When a page is deleted, moderate associated
notifications. When it is undeleted, unmoderate.
* When a notification cannot be rendered
(canRender() returns false), moderate it.
The biggest advantage of moderation over mark-read-and-ignore
is that those notifications are filtered out at the database
level from this point on. They are not re-processed every single
time and do not affect the number of notifications returned by
the API.
Bug: T140327
Bug: T140836
Bug: T141463
Change-Id: Idefe78408fd584c13aaa9174cee3055539d92848
To allow individual notifications to be
marked as read/unread or moderated,
bundles are created by grouping associated
notifications when they are fetched for display
instead of when they are created.
From a product perspective, this change doesn't
introduce moderation or expandable bundles but
it counts each individual notifications.
For instance, the bundled notification
"3 new topics on PageA" now counts as 3
notifications.
Bug: T93673
Bug: T120153
Change-Id: Iacd098573efd92bb1e3fcd7da4cd40cea9522f15
Check for proper unserialization in EchoEvent::loadFromRow(), and return
false if not possible. Callers were updated to check for a false return.
Bug: T73489
Change-Id: I33867aa9bbbc5f0ecfe0d2a9e1b03eb1a937ae83
This seems better for availability than stopping the world
and rolling everything back (or just throwing post-commit
errors that didn't stop the original change anyway).
Change-Id: I816b3cb5f0d26de608e620a01571a332aa832c05
We only track revisions for some notification types, others still
reference usernames, but don't check for suppression status. If no
revision is available, use User::isHidden() to check whether
EchoEvent::getAgent() has been hidden.
Bug: T110553
Change-Id: I31e635e365bbb0f6c6ac63be2bdb07e5e2d67c96
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
