Fix off-by-one edit count for ThankYouEdit notification

Incrementing user edit count was moved to a deferred update in
I0d6d7ddd91bbb21995142808248d162e05696d47
That causes the notification to lag behind, and the thank you notification is
sent for your first edit on the second, you 10th on the 11th, etc.

This change simply assumes one more edit than the current count unless it is
running from the CLI (this is needed for the test to continue to work).

Since the update job is mergeable, it is possible that a certain value will
be skipped and the notification for it never sent. See task for moe details.

Bug: T209541
Change-Id: Iea61b0f525be25f63f50582933a16a79a52e141f
This commit is contained in:
Stephane Bisson 2019-03-04 10:49:19 -05:00 committed by Kosta Harlan
parent 8de5066b24
commit 408721a357

View file

@ -547,7 +547,7 @@ class EchoHooks {
// test for them reaching a congratulatory threshold
$thresholds = [ 1, 10, 100, 1000, 10000, 100000, 1000000 ];
if ( $user->isLoggedIn() && $status->value['revision'] ) {
$thresholdCount = $user->getEditCount();
$thresholdCount = self::getEditCount( $user );
if ( in_array( $thresholdCount, $thresholds ) ) {
DeferredUpdates::addCallableUpdate( function () use ( $user, $title, $thresholdCount ) {
$notificationMapper = new EchoNotificationMapper();
@ -607,6 +607,20 @@ class EchoHooks {
return true;
}
/**
* @param User $user
* @return int
*/
private static function getEditCount( User $user ) {
// When this code runs from a maintenance script or unit tests
// the deferred update incrementing edit count runs right away
// so the edit count is right. Otherwise it lags by one.
if ( wfIsCLI() ) {
return $user->getEditCount();
}
return $user->getEditCount() + 1;
}
/**
* Handler for EchoAbortEmailNotification hook
* @param User $user