Add a global-wiki 'mark all as read' to the Special:Notifications page.
The 'mark all as read' will makr all notifications in the given
wiki. The context of the wiki changes when filters are chosen,
and so the message of the button changes as well.
Bug: T115528
Change-Id: Ibd9dcdf7072d6cbc1a268c18e558e6d0df28f929
This organizes the operation of seenTime so we can store and
follow up on it based on different sources, as well as update
it correctly remotely when needed.
Change-Id: I629ecfc84999be998b45c9c7adb00ea7e3e51742
This would make the wiki names localized to the current user
interface language, rather than the wiki language.
Bug: T139807
Change-Id: I2b787e1486819d6833e169ac6db519cd36a3c3eb
We need the API to return the notifications for the special page
in timestamp order and not read/unread order, so that the 'continue'
value is still correct.
On top of that, if we have many unread notifications, they should
still be placed according to the dates, so the API must bring back
proper result.
In this fix, we add 'unreadFirst' to filters, and only use that
filter when needed (namely, in the popup)
Bug: T136885
Change-Id: I3018d09b009d735402d83074a5ffcd14ea1c242a
When we fetch the pages per wiki, the API returns an object that
defines the local wiki we are in as its dbName; this then gets
stored into the model as the source, which forces us to check against
the dbName whenever we want to perform an operation so we can tell
the API layer to fetch and perform the actions locally, rather than
use a foreign API.
The term 'local' makes no sense for naming the model (and upcoming
tech debt work will fix this) but it makes sense in the context of
the API layer -- and hence, the source name should follow suit.
This fix makes sure that the local wiki objects always have their
sources defined to be 'local', and thus making us use the test for
dbName in very specific points (when we get the data) rather than
throughout the codebase, randonly.
This is also the first step to allow proper updating of things like
seenTime accross wikis, especially in cases where we view a remote
wiki as if it is local (in the Special:Notifications page)
Change-Id: I94633a1cd074580cbc5029d7c75d179e908e5c52
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
This will allow us to let the user click filters quickly, effectively
changing the promises sent to the API, but let the API only resolve
with the latest requested promise.
Bug: T136895
Change-Id: I698a2b8eced6d8ee997efef353697d27d92cfb2f
Add a sidebar with cross-wiki sources and pages of unread notifications.
The filter allows the user to fetch notifications from a foreign source
and specific pages if those exist.
Bug: T129366
Change-Id: I57d827a47f80274d75364c2099a9624049a26834
The zero results can either be because there are no notifications
at all for this user in the local wiki, or because there are no
results for the specific filter. Both messages are used for either
case.
Also, clean up the display of push/pop pending for the inbox widget
and hide the label in case the message count is 0 or 1 notifications
as it is unhelpful and irrelevant in these cases.
Bug: T136586
Bug: T136574
Bug: T129363
Change-Id: I1465f772bb9f5247df645d6612f951e5fd7d38cf
Changing the way Echo's front-end architecture works to work with
model-view-controller methodology.
Change-Id: I97862402c41bc04dd41cd08d79f19ff677340249
Some complexity is now gone. We didn't currently have a good justification
for a the APIHandler factory: the apiHandler caller would have to specify
(variable `foreign`) what kind of handler it would like to initiate anyway,
so it might as well just inject the object (which makes the code easier to
follow, decreases bugs risk because there are less code paths)
This also gives the caller more control of the API handlers:
registerForeignSources will now be able to do more. Now it can e.g. create
1 object that is shared for multiple wikis (to do lookups for multiple
wikis at once)
Also renamed addApiHandler to setApiHandler (it just sets the value it needs
without checking if it already existed anyway)
Change-Id: Ie1814c5bf1a1f0e5607033beb506df67f3585b24
this.api is used in APIHandler.createNewFetchNotificationPromise,
so we should make sure it always has a valid this.api
Change-Id: Id476661fb427adbbb3c5741737c293c32ad8a27e
Fetch cross-wiki notifications by asking the local API, but still
maintain the ability to send remote requests to the foreign wikis
for mark-as-read operations.
Bug: T130636
Change-Id: I48524cb9dff43257a401d7483e939edfb042b928
I thought the name was confusing, and would be even more so
if we get real notifications from other sources.
Meanwhile also split $crossWikiSummary into 2 properties:
- 1 with the class
- 1 to indicate if it should be used
Change-Id: I0e83be7924c8c77680ea1ada3f2bd6a190ce6149
It's (mostly) unused, and it would become problematic once we have
notifications from multiple places (where those ids could conflict)
Change-Id: Ib3bb5ae1e5689037b38290c9ce3d8691f52582b0
The flyout loads no more than 25 notifications
from a given source. Using those in-memory notification
objects to count how many are currently unread (and
update the badge) produces a result of at most 25.
This patch extracts the responsibility or counting the
unread from the Model/Item/Groupitem structure into
a new UnreadNotificationCounter class. It receives
estimated updates from other components and synchronizes
with the server after markRead/markUnread operations
have completed.
Bug: T129726
Change-Id: I9af4defc00dd491ed2b355eb4e85073476e08ce7
Both in the order of the cross-wiki bundles themselves, and
in the message in the notification body.
ForeignNotifications tracks timestamps per wiki per section,
and exposes these through getWikiTimestamp(). ApiEchoNotifications
adds these timestamps to the sources manifest, and also sorts
the list of wikis by timestamp (it'd be nicer to do this in
ForeignPresentationModel instead, but then we'd have to create a new
ForeignNotifications instance which causes a duplicated DB query).
NotificationsModel receives the timestamp for its wiki as its
fallback timestamp, and makes getTimestamp() return this value
during the pre-population phase. This causes its parent to
automatically sort it correctly.
Because the timestamp of a wiki depends on the section (alerts vs messages),
we can't put it in the global sources manifest at the top level
of the API response. Instead, get rid of this global sources
manifest and put all the sources data in the foreign notifications
directly. This allows us to specify different timestamps, and also
allows us to get rid of code in EchoApi that was already remapping
the API response to this format.
Bug: T130298
Change-Id: Ie083fbb1ccaf74fbe804633d87ef03c9e71b120f
Add a 'mark as unread' to all unread notifications and allow them
to be marked unread. These notifications will no longer be automatically
marked as read when the pages they refer to are visited.
Bug: T73564
Change-Id: I677d3c0399e46fd7c35531df1cc0e61db2d4eb1b
Split and refactor Echo network handling and create a proper API
layer for the UI to use consistently. Split Echo's API methods into
its own module so they can be loaded along with the initialization
script and manage the API requests.
Change-Id: I0526a14bb8cc0d9729a303e24ab6e43259cc86bb
