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
The $cached and $dbSource parameters are now unused, so remove them.
This affects get{Notification,Alert,Message}Count and
getLastUnread{Notification,Alert,Message}Time.
There are some callers in other extensions and in skins, but none of
them pass any parameters (except one, which I fixed in Ice42930280da).
Change-Id: If6f10c4f163ecb1def5a150656a60d1ab5f44d52
As suggested in 26505b170adb24a6ae68945920db322c9382e470 for better
readability. Also the sniff now knows about the maintenance script
Change-Id: If3ab122c1fc12fcfbce777881ca21ecd99fb2a70
Format user-rights reason as plain text
in both web and email since links
in notification body are not supported.
Bug: T172636
Change-Id: Ief5ff0aff18aad070f4388e075b5aae072d8f101
The centralIdsFromNames() includes optimizations and error checking
that was not in the original version.
Bug: T178313
Change-Id: I3d6334f2e81f3cee66b36690734f70958fdcefdb
Various selectFields() methods were deprecated in MediaWiki core change
Idcfd1556, replaced with getQueryInfo() methods.
Change-Id: I5d62ad76fdb64a9c6efd228f27e9b5f512f17d5e
Depends-On: Idcfd15568489d9f03a7ba4460e96610d33bc4089
To access user_properties in the WMF cluster, we must use the standard database connection instead of the echo connection.
Bug: T173475
Change-Id: Ic7344e4521b30055f7986aefd61712e6c6a0052c
The echo mute list uses user names which are not stable. User ids should be used instead.
Bug: T173475
Change-Id: I947bcf37a8f85aaa105776d368dbd0ab76823aeb
Follow-up to Id539a7db8d8f5e902177845bd212b4d6c2500f89
Pass the revision id instead of populating the request
object.
Change-Id: I4567d8b08999558d86c48aea5912de0e52bcf241
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
In rebuild mode, we only process users who already have
a row in the euw table. This reduces the number of users
we have to process significantly. Thanks to Stephane
for this idea.
Also, don't force a recache of the alert and message counts,
it's OK to fetch them from cache. We also don't need to invalidate
any caches in this script, because the transition flag from
Ibcc8ac102 will ensure that the cached global counts are
correct.
Change-Id: I69c54cac47468647df2778b2d82f1b5dd9e574d3
Better idea: invalidate caches in this script, and write
a separate script to recompute existing euw rows.
This reverts commit c83af257d2.
Change-Id: I57bccfb726eada646cb318206d9091a20d59dcf5
This causes it to update the notification count cache as well.
Should we perhaps rename it to recacheNotificationCounts.php?
Bug: T132954
Change-Id: I540c4296f4fbadcf2267d77b53f71ee5c2eb8b52
This script was supposed to be run in production in 2013, but that
never happened. It was also never added to update.php.
* Use makeTitleSafe instead of newFromText, for correctness
* Fetch the columns that the update generator needs
* Replace wrapper for private method with closure
* Make the maintenance script logged
Bug: T136427
Bug: T50059
Change-Id: I6c2972120189f035483b5ca49610c008c4ba2c88
This maintenance script sets the correct read_timestamp
on notifications that have been read as part of a
bundle.
Bug: T136368
Change-Id: I735fb230a14f95e0a983e733ec160eb8811b3197
Previously, getNotificationCount() only looked at local notifications,
and foreign notifications were added in separately by getMessageCount()
and getAlertCount(). This didn't make any sense and resulted in
counter-intuitive things like I4d49b543.
Instead, add a $global flag to getNotificationCount(). If $global=false,
the local count is returned as before, but if $global=true, the
global count (=local+foreign) is returned. If $global is omitted,
the user's cross-wiki notification preference determines which is returned.
Update getLastUnreadNotificationCount() in the same way, since it had
the same issues.
Also add caching for global counts and timestamps, using a global
memc key.
Bug: T133623
Change-Id: If78bfc710acd91a075771b565cc99f4c302a104d
Also added the force (-f) option to
bypass the confirmation. Very useful
when using the script in a loop.
Change-Id: I98c3e0408033903f8e2fb0afab773d4952a4e6d3
