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
echo_notification isn't the only table that refers to echo_event;
echo_email_batch does too, so check it as well.
Change-Id: I6663c8bb83a991ee663eb1616583fde8eee46751
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
column event_page_namespace was dropped from the database
When running the updater for sqlite on a fresh install it fails
Function: Wikimedia\Rdbms\Database::sourceFile(
/workspace/src/extensions/Echo/db_patches/patch-event_variant_nullability.sqlite.sql
)
Error: 1 no such column: event_page_namespace
Change-Id: I397e601dd9db45fc34669c43df5f9dd8d337ed95
When the location on disk of an icon is known,
load its content and turn it into a data uri
for the <img> tag.
Otherwise (when it's only configured with a url),
use the url in the <img> tag.
Bonus: the rasterized icons were a bit blurry
and they are now crisp.
Bug: T55479
Change-Id: I8b5d7f09d8181f22927b8d4712505212ea1a10b1
