When we mark an entire bundle as read, we don't care if it was opened
before or not - we call the API for the list of sources and their items
and build a list of IDs to mark as read in the remote source.
Then, we make sure that bundleIDs are expanded, added to that list.
Previously, we then sent those IDs to 'markCrossWikiItemsRead'
which marked the item IDs in the remote wikis as read.
markCrossWikiItemsRead is also expanding item bundle
IDs (correctly, because we also use it when we mark individual
xwiki items, and they should be expanded)
However, in cases where we mark individual xwiki items, the
model list is already filled, so markCrossWikiItemsRead trusts
the models to deliver the sub items (and then expand on their
IDs properly)
In the case of marking an entire xwiki bundle as read without
opening it first, however, that operation is not only redundant,
it produces a problem where the models were not yet filled
(because the xwiki bundle wasn't opened) and so we get empty
array of IDs, and the API has nothing to mark as read.
The solution is simple in this case - skip this method for working
with an entire bundle. It's both a redundant operation and the
wrong model to check. Send the information directly to the API
instead.
Bug: T142143
Change-Id: I4ed3bbc5c83290ed5791060b124840b1c3b12a75
This fixes a bug where changing the read status of any notification
in the messages popup would remove the "You have new messages"
banner even though there are still unread talk page notifications
in the alerts popup.
Change-Id: Ic6b3d2c9fa764be2da8f9bd9b0d10311857f8509
A browser bug causes the badges to be pushed down by 1em in IE11
and below, but not in Edge. The only way I could find to work
around this was to add top:-1em; in IE browsers using CSS hacks.
Bug: T142053
Change-Id: If240f7281dd795085c003af524da294d5bf5ff76
Not sure why it's doing that, because the SVG has explicit 24x24
dimensions, but adding these (theoretically unnecessary) CSS rules helps.
In Chrome/FF (as well as more modern IE versions), this is a no-op.
Bug: T142042
Change-Id: Ibb293f453dc79de90690ab48f522e43d3e66b8e8
Foreign notifications, though non-expandable, can represent
bundles (4 new topics on your talk page). When marking one
as read, it's important to provide all the IDs that are
part of that bundle. Otherwise, only the dynamic base is
marked as read and the bundle shows up again on reload
(3 new topics on your talk page).
For bundles that do not include the count
(The description on Flow_Page was edited multiple times)
it looks like the mark-as-read action did not work.
Tagging with T140309 as it may explain it but not 100% sure.
Bug: T140309
Change-Id: I19c9eb18669b7cad8173c966392a6e5977018121
This was causing a strict standards warning due to inconsistent
parameters.
Rename it to getUnreadNotificationPagesFromForeign . Since
this does a data transformation (it doesn't have the same response
structure as the parent), I decided to rename it rather than
make the parameters match.
Change-Id: I259def82b933cbde0e94a49f9a9d6f754f681808
Avoid duplicate by looking if the notification
already exist.
Change-Id: Ie519d13cd0ab03919f70da90d58c82a214c74b49
Depends-On: I79194c41d6b2fd84ad658909a2941d9d3d28d94e
Bug: T128249
Make everything a little smaller, decrease spacing. In order to
make the icons smaller, we had to override the content: url(...)
into using background-image with sizing.
Bug: T141923
Change-Id: Icacb15871c824ae845acc937973fb230b05b489a
Make it optional through the unpgrouppages parameter, so that
generic usage of the unreadnotificationpages API is still possible.
In the front-end, store which display title maps to what set of titles,
and pass in the full set rather than just the display title when
filtering by a page.
Bug: T137502
Change-Id: I443ca00ff5e5d36fd6910101226358942e6aa8ee
For mobile view, only display 1 prioritized action in the items,
and for general desktop view, stick to the default 2.
Bug: T141788
Change-Id: Ibf386ee598553ecfb717f07f02688034bbc338c8
The fade in/out animation is asynchronous. This means that if we are
sorting multiple items one after the other, by the time the item faded
out, it will be reinserted back into the wrong position, breaking the
sorting.
This also broke the promise of OO.SortedEmitterList whereby all its items
are always in order.
The way to fix this was to force a better synchronization with the item
order while we hide and show the item in its new place. To do that,
a new widget is created as a fake clone of the old one, in the original
position of the old one. The original item is then reinserted (while hidden)
to the proper location -- preserving order. The fake clone is then faded
out, and the real item is then faded in.
For this to work properly, the cloned item had to preserve some of the
original item's information, like timestamp, foreigness and id. However,
since both the real item and the fake new clone have the same details,
the clone fakes its ID by adding a fraction to it - promising that the
fallback in case of equal timestamps (which happens on the real and
cloned items) will still resolve with some decision about the placement
of the items rather than (falsely but understandably) decide they are
both the same.
Since this whole animation is somewhat of a hack, the list now has a
configuration parameter to turn the animation on.
The animation is on in the popups, but off in the special page.
Bug: T141419
Change-Id: Ic7c35e5ddefc51bf7fde497eab36414b4dddcd9e
This will make the mobile view show unseen state if any of the
badges have unseen state rather than not show it if one of the
badges was more recently seen than the other in desktop.
Bug: T141404
Change-Id: I27109ee6a24831d58767f9bd13ed58e54094aee1
Adds new notification type and icon for successful mentions.
Complements existing test to consider successful mentions.
Bug: T139623
Change-Id: I7a77b40e8b14c95cadb9023065ee916247feacf9
