Follow up on Icfc85167a636bef95daab2.
Bug: T221163
Depends-On: I31d819f4453032da8deb117254b954fba058e0a3
Change-Id: I3d997f9e8d4bd1566ec6fd8fe2d33be5161458b3
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 creating the various notification sources,
the server was indexing them with wfWikiID() but
the client was using wgDBname to find which one
is local and which are remote. On some wikis,
like TWN, wfWikiID() includes a db suffix so
the JS app on Special:Notifications is failing to
find the local source and errors.
Bug: T167336
Change-Id: Id60f723b615fb7db54a6f17b1c1be20dfe98e36c
When deleting echo_notification or echo_email_batch rows, also delete
the corresponding echo_event rows if no other echo_notification rows
or echo_email_batch rows refer to them.
Bug: T221262
Change-Id: I416ff107bd000a0cfac102408c993f8bec2d0286
Added a test that creates a new user and checks that they have a welcome message when notices is clicked.
Bug: T217051
Change-Id: Ia5808ebcedcd91f740cce646f4aa0576ef6d378f
This will allow us to remove notify-type-availability for individual
types, and manage all of it on a per-category basis instead.
Bug: T221264
Change-Id: I78ed6782be8b819cf25cceabb4ea794b15eacafd
Add a preference in the notifications section to allow
disabling the 'thank-you-edit' notifications completely.
This is useful to editors active on several wikis. They can
disable it in global preferences and stop seeing them globally.
Bug: T169924
Change-Id: If6716bb98ed2309813536a5834e03833fb537dcf
Remove echo_target_page rows associated with the echo_event rows we're
deleting, and also add a separate pass that removes any remaining
orphaned echo_target_page rows (this can happen if the script was run on
the wiki before this logic was added).
Bug: T221261
Change-Id: Ic3b590fb3ac3de4c2e38877d26944367b177235a
* Clear echo_event before the test. Otherwise it contains
a 'thank-you-edit' event that offsets everything.
* Use standard $this->db
* Use standard ~~~~ signature
Bug: T67336
Change-Id: Idd09aa107d01038d03b689d9086f65a9fb7b653a
$wgEchoSectionTransition was introduced when we moved some notification
types between sections (alert, message).
$wgEchoBundleTransition was introduced when we made bundles dynamic
and expandable.
Both flags have been OFF for years and are not needed anymore.
This patch removes all traces of them.
Bug: T140710
Change-Id: I16a5d54b09e71997f80208db6f4fbdb040d03ab1
EventMapper->fetchById() has retry on master built-in but it doesn't
kick in in a Job because the load balancer is a new instance and doesn't
know about previous writes.
This change makes the job always read from master to make
sure the event is found. It is going to write to master
right after anyway.
Bug: T204894
Change-Id: I9a2873234f1dd5416e6c2bedeb904880d1f79562
It was sort of checked in an implicit and roundabout way, in the sense
that the preferences page checks this and forces the relevant
preferences to on or off. But this was difficult to discover, and it's
not clear if this works correctly when defaults change.
Instead, explicitly check whether the requested notify type is available
for the event's category. Also rewrite the entire method to use
array_filter().
Change-Id: I9502a42fc705b2e56ef5edab433f1804f2924359
Generally applicable, but intended for users affected by the
login-success phantom notifications bug.
Bug: T220762
Change-Id: Ica428bfc19e0555564ca04d80ac5009197401aaf
This was attempted in I6f87797701, but didn't work. The reason is that
notify-type-availability can't be set on a per-notiifcation basis for
visible categories, only for hidden categories. For visible categories,
it has to be set at the category level.
Bug: T219444
Change-Id: I6b6dd1ae6be549de0f6026841966f87527dd2365
