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
Also test it more meaningfully by setting up a mock database and
asserting that the right DELETE queries are issued.
Change-Id: Id39723b92118e98d9c9f0cd7381e9396dce67c17
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
* 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
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
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
getNotificationCount & getLastUnreadNotificationTime have an
argument $cached that allows cache to be bypassed & read from
DB. That result is then stored to cache.
In practice, it seems to be used only for cache invalidation.
getLastUnreadNotificationTime didn't allow to specify the DB
to be read from, and EchoNotificationMapper::fetchUnreadByUser
only read from slave.
So when we wanted to invalidate the cache, we would end up
immediately repopulating it with data from a (potentially and
likely) lagging slave.
I've made it accept the DB type, similar to getNotificationCount.
Bug: T98421
Change-Id: Ie4b09eeb04b9827b454cb2d92ee8c674bdd59a19
Previously this was loading 25 unread notifications. If less than 25 were
found it would add in 3 read notifications so it wasn't empty.
This patch changes things around to always return 25 notifications if the
user has at least that many. Instead of backfilling a static count of 3
we backfill 25 - $count with previously read notifications.
Change-Id: I723316486216d7b9dacfcc9765c1a8212e973518
Has a performance impact, so this depends on deploying the job
that deletes older notifications.
Bug: 69919
Change-Id: Ia485c853d1b04c3c85e25e6a12f5060a046e9b11
The special page will now not auto mark a notification as read if
it has a target url. Currently no notifications have target urls
but this will be changed in a later patch...
Change-Id: I9bd71d59391189d5d761ab5f1c84af0bc3554be0
This was supposed to merge master into the two_tabs branch, but it was accidently done against master instead
This reverts commit 06ee936e92.
Change-Id: I98da735b7d5c103399a2478286d1420243df6ba4
* This will be used for the unread notifications in message overlay
* This will be used to "mark all as read" based on sections ( event types ),
since we can't do updateJoin. We could set a max update limit like 3000,
and use this to do "mark all as read", this would handle majority "mark all as read"
use cases. This would also prevent updating big amount of data on a web request
Change-Id: I2a9103a73d0aa91a52d5c0233e946a0ef979f96d
* Shared function can be put in the abstract class and this also enforces some interface methods
* Initialize a default dbFactory when it's not passed to the mapper
Change-Id: I1033dafaa90a1f683fbe9ad69bed04f4844e357b
* Get rid of EchoBackend by separating responsibilities into smaller objects
* Move main fetchNotification logic from API to a more appropriate place
* Add more unit testing coverage
Change-Id: I42f4d7566543332588431c21c220c0d64d026b70
