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
There are about 200 of such generic "array" type hints in this code base,
the majority in @param tags. I started with what I found most relevant:
@var and @return tags. I might continue working on this later, but
wanted to stop for now to keep this patch moderately small.
Change-Id: Iff0d9590a794ae0f885466ef6bb336b0b42a6cd3
Also test it more meaningfully by setting up a mock database and
asserting that the right DELETE queries are issued.
Change-Id: Id39723b92118e98d9c9f0cd7381e9396dce67c17
Changed to interface, because the result of IDatabase::select is
directly returned and now the same type
Change-Id: Ib77e1f5c26ebf0b474dc944b15d6ef671a88e836
The return value from the method is only suitable for passing to
$db->insert(). To get the inserted ID, you need to call $db->insertId()
even if $db->nextSequenceValue() returned non-null.
Bug: T164900
Change-Id: I466fd372804927b3ad72125c7a69d253bd7a24f8
Only retry lookups if there are multiple DB servers and
changes were made in this request. This same logic is used
in a couple of places in MW core, like WikiPage::loadPageData()
and Revision::newFromConds().
Bug: T164505
Change-Id: If1af363f9687019864b5eaef72ffe0bc824a2223
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
Removed fetchByTypesAndPage since it is now unused
Fixed fetchByPage to select simple * instead of
echo_event.*
Bug: T105890
Change-Id: I486f27501a649d5368305965d2cd012afe0915b2
* 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
Uses the magic value '[]' to mean 'no title'. This is a bit ugly,
but I think introducing an additional ¬withouttitle=1 parameter
is uglier and results in more code.
Change-Id: I83278182aeaf3905eb0f3e24c4c6c247720b1e76
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
Formatters based on presentation models for
individual event emails and digest (daily, weekly)
plain text emails.
Bug: T121067
Change-Id: I4eceaf521315adab7429a8a73ffca70ebcddab86
Notifications were being marked as read in response to a click event
in JavaScript, but that causes a jarring effect in the UI, and it's
not reliable (the browser could abort the AJAX request).
Instead, add ?markasread=XYZ to the end of every primary link URL,
where XYZ is the event ID.
Bug: T133975
Depends-On: Icb99d5479836fea25a47451b5a758dd71f642f71
Change-Id: I8047d121584b43e6172463a50ad0e0de5f7fa73c
This reverts commit e372f3ce6f.
The previous attempt was broken because
EchoTargetPageMapper::fetchByUserPageId() returns a list of
EchoTargetPage objects, not a single one.
Bug: T117531
Change-Id: Id02a025e3736a7b92d9d6fb8adf29ef674f8e2fa
We calculate how many messages and alerts are being marked as read, and
subtract them from the count since the database and caches won't be
updated until the end of the request.
For performance, we also get the event_type while doing the
EchoTargetPage lookup query to avoid having to query it individually
later on.
Bug: T117531
Change-Id: I0d9302adf1b4b07a4ff26a04b00d4498aa3fe7ee
Right now, it'll only respond a certain, fixed, amount,
not allowing you to paginate the list.
Note: haven't properly tested all possible cases yet!
Change-Id: I84761b13a1b9203cb8e3fcc80941d739cd28659f
The only difference at this point is that fetchByUser initializes
the EchoNotification object with $targetPages. It doesn't really
matter that it doesn't have the target pages, since fetchUnreadByUser
is currently only used in the flyout, where those target pages aren't
used. But regardless of what method was used to fetch the data, I
think the data should be the same.
And now, there's less code duplication...
Change-Id: I04c7b98794af5427a2217dd337108e7eea1e65c5
It's basically impossible for DatabaseBase::select() to return false now
that ignoreErrors() is protected. So always return an array so callers
don't have to worry about false.
And remove a test that checked the result if DatabaseBase::select() did
return false.
Change-Id: I9ca8511585403d8c0ec262898ad4e61c2b038d51
Although it wasn't here even before
c94c3f3dad , loadFromRow will make
use if it if it's present. Otherwise, it's the current timestamp
(which seems odd; if we really don't need the timestamp in a
particular scenario, null would be more straightforward).
This is also public (getTimestamp()).
Change-Id: I9d88d86dde5b7f9b5965c81225a2aab4354c2baa
