Do not emit sortChange for toggleSeen, because every sortChange
creates a fake widget with a flipped 'read' state. There is no
reason to emit the sortChange event in toggleSeen anyways so it
is safer when only emitted in togglRead.
Also, make sure the controller always updates the correct seenTime
from the API when fetching local notifications. This was done for
the special page method but was overlooked for the fetching of local
notifications. For the most part, it shouldn't be affecting too much
because the SeenTimeModel is initialized with wgEchoSeenTime (which
is local) but updating the controller with the API response is the
safe thing to do, and will also cover cases where a tab was open,
notifications were seen in a different tab, and now the popup was
reopened in a "stale" tab again.
Bug: T143067
Change-Id: Ie261e32db28926d04fe14f7badd9d287ddc52749
We have to override a CSS rule that tries to make all <a>s blue,
but not override it so powerfully that the real link in the footer
notice isn't blue.
Change-Id: I5a91419aab7cf6d6fe10c8e707168b52c2451cd8
Adds common bundling including messages and icons.
Bundling relates to revision now.
Changed order how notifications are generated. Now errors will
show first, since they are generated last.
Bug: T140224
Change-Id: I1069aeb5523db8710da4e8e21065bf447d031e3c
Seems to be fixed by different changes, and now this change
is causing trouble, moving the badges up off-screen.
This reverts commit 0b7f8712a9.
Change-Id: Ia5a0a6b6be3698436a043aee111f251709c22f20
What this really does is:
* Change the forced width of the <a> to the width of the icon
(rather than 1.25x the width of the icon)
* Change the alignment of the :before from 40% to 50% so it
stays in the middle (1.25*40=50)
Change-Id: I0399a20fc84e59fcbcf69da509a4d8bfa9b54a08
The color: transparent; hack was being overridden by a color rule
that's only in effect after the popup is opened.
Change-Id: I2f415619603ccadb625ed2482c25fde78765fee4
It's a lot easier to set 'color' back to the desired value than 'font-size'.
As an amusing side-effect, the hidden text will appear when selected, and
it will be possible to copy it.
Change-Id: I7a7ef8e60f514743c9cb65bcef3ba4e869f5b7b7
I think everything works the same. Some older browsers (IE 10-11,
Opera 12) have funny issues with SVGs in 'content'.
.mw-echo-notifications-badge now has 'height: 24px', as it must be
at least as high as the background to display it. We no longer need
.oo-ui-popupWidget to have 'margin-top: 7px', that was a workaround
for the badge having smaller dimensions in CSS than in reality.
This also allows us to significantly reduce the amount of Monobook-
specific CSS, because we now use the background-image approach for
all skins.
Bug: T142042
Bug: T142248
Change-Id: Iaa22202dbd5b5eb7a9b1ef47d068e80764ed982f
The actions logged:
* Popup: Mark all notifications in the popup as read
- Event ID is omitted
- Context 'flyout'
* Special page: Mark all notifications in current wiki
as read
- Event ID is omitted
- Context 'archive'
Bug: T127955
Change-Id: Id7c091f9e0cf0dd3745d33e335ab44706581d7f3
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
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
Adds new notification type and icon for successful mentions.
Complements existing test to consider successful mentions.
Bug: T139623
Change-Id: I7a77b40e8b14c95cadb9023065ee916247feacf9
- Adds global "$wgEchoMentionStatusNotifications"
to activate mention status notifications.
(must be set before extension is loaded)
- Adds notification types and icon for some basic mention
failures.
- Adds failure and stats for anonymous IP.
- Adds check for links to user subpages.
- Adds config var for max mention notifications allowed.
- Bundles notifications.
- Refactors test for the event generation and adds tests
for unknown users, user links with subpages and failures
for too many mentions.
Bug: T136326
Change-Id: I388bdc3714feb9a2865a5ad10dbeabb0a6a09a4f
* Add ISO 8601 date format to notification output
This is actually supposed to be the only output date format used,
per https://www.mediawiki.org/wiki/API:Data_formats#Timestamps , but
I'm not doing anything to deprecate the others right now.
* Change wgEchoSeenTime to use ISO 8601. mwgrep and extension grep do
not show any usages. However, since it is a breaking change, to
minimize disruption, I'm also using this opportunity to change
'message' to 'notice'.
* Remove wgEchoInitialNotifCount. I was going to also change 'message'
to 'notice' here too, but then I saw it was totally unused.
(It was read in Echo to populate a JS variable, but then it was
unused.)
* Make sure the Special:Notifications page aggregation by days is
done by local days, even though the timestamp per item is still
UTC. This is to make sure the days are displayed correctly in
the local timezone.
* Change all reverse sorting callbacks to handle comparisons of
ISO 8601.
Bug: T141413
Change-Id: I20271345c7d350dc3e7f467288e5cdc98e6250cc
Now that we have the cog menu, it should be placed correctly in
mobile and the "preferences" link should be hidden.
Since MobileFrontend doesn't have the personal toolbar, and we
can't cheat by using jQuery and grabbing the url of preferences,
we have to get SpecialNotifications.php to output the urls
to a wg variable and reading it from there.
Bug: T115528
Change-Id: I6a69823d6f75c376c04e9a21d79916321e417178
Bundles only have a header, no body, so when we include excerpts
in bundle headers, we wrap them in <em> tags. This change
makes these excerpts the same color as the excerpts in the
non-bundled case.
Bug: T139960
Bug: T141034
Change-Id: I6a14274b42ba672ab1366c0dd106ea0847db6404
As pointed out by Roan, this is the consistent way ooui elements
are displayed when they have a drop-down menu.
Change-Id: I36ecdd4cf6374dff34be15b24959548887788130
Alert popup can now also have talk-page related notifications, so
we should make sure we listen to 'allTalkRead' event when it is
updating as well.
Bug: T141047
Change-Id: I1317efc63b503bd1a55734ebe377ff4c617fe485
And change all CSS and JS dependent calls/tags based on the new
tooltip message and ID of the personal tool <li> item.
Change-Id: I136fabe5710f90da10eb8d4afe92acdb77571eec
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
As a first step for mobile support, make the page responsive,
hide the sidebar, and slightly adjust button/title positions and
sizes so they fit in a small screen.
Bug: T140687
Change-Id: I98f264948a57924f6370a861381456ce9c82f8d8
When there are only foreign notifications, marking them all
as read empties the flyout completely. With this change,
we now show the placeholder widget with the 'no notifications'
message instead.
Bug: T132202
Change-Id: I7ee38b160ca03c08711670a3296ba4ab45a5eb6c
We need a fixed-width CSS table with a number of fixed-width
cells and one cell that takes up the remaining width, with
text truncation. This is a pain to do with CSS tables,
but this trick I found on StackOverflow[1] works well:
wrap the contents of the cell in a div that's position: relative;,
containing another div that's position: absolute; width: 100%;
[1] http://stackoverflow.com/questions/7569436/css-constrain-a-table-with-long-cell-contents-to-page-width
Bug: T140349
Change-Id: I507f915f06185c767d7a5c8edbff6c341e07b6e2
When we are viewing a certain read state filter ('read' or 'unread')
the visibility of items should correspond to that state even when
the user marks a specific item as read/unread. That means that the
system should remove these items from view when the action is taken.
In this commit:
* The controller makes the judgment of whether to remove items when
read/unread action is taken, based on whether a filter is set.
* We clean up the terminology of discard - no more 'remove' - to
make sure we have consistency in the code.
* Related: The 'discard' event is now scoped within the hierarchy;
meaning, lists emit 'discard' when an item is removed, grouplist
emits 'discard' when a group is removed, and the manager emits
'discard' when an entire notification model is removed. This
means we can actually have proper hierarchy and organization with
a single event, and not worry about clashing between the intentional
'discard' action and the event 'remove' that is also used while
resorting happens.
* The model manager emits a discard event when a model is removed
so that the general list can listen to the manager and remove an
entire batch of items if needed.
* The pagination model now updates the count for the current page
rather than some vague notion of the last page. This is also
updated when the controller removes items, so we can get an
accurate count in the page for the number of notifications that
are displayed.
Bug: T136891
Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
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
The message for tooltip-pt-notifications-message was removed to comply
with the new naming. The problem is that in the back end, sections are
still defined as 'message' vs 'alerts' and the sections in the user
toolbar are defined with those terms. In no-JS mode (which is before
the user clicks any of the badges) this tooltip is created automatically
by MediaWiki based on class names.
It's easier to return the message key with different text for translation
and wait for the bigger tech debt to correct all instances of 'message'
to 'notice' (including in the API, which would require a much more
massive work)
Bug: T139520
Change-Id: I6368b63e38f64aa065f2580df812de1c63a93716
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
