- 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
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
Instead of 'cheating' and externally aggregating the itemUpdate event
we should just let the relevant (non-xwiki) models aggregate this
centrally and properly, and include it as an offered event.
Change-Id: Ibe528fe971e1be8309a97275b1a1be8979306ff5
Following up on setting max-width, this actually should be strict
width for the moment (until we decide on more responsive design)
since without restricting width, the notification view becomes really
thin and compact if the list contains notifications that have short
titles and descriptions.
Bug: T138433
Change-Id: Ia663f7968033b01f3553a326f70736cc6a6a54a9
This is to make sure that concatenation of text inside items works
properly given CSS table-layout.
Bug: T138433
Change-Id: Iae32cbf82cdb91880c7ccd7df14d167eb75527cf
Marking local or xwiki notifications as read
are different operations that require different
information. Call different functions on the
controller.
Bug: T139114
Change-Id: I824ca668c31ab41d101c632442c91d3a8a1e5c5a
If there are more than 2 prioritized actions, put those actions
in the dotdotdot menu.
Also, correct the name of a variable from "isInsideMenu" to what
it actually represents, which is, in fact, "isOutsideMenu"
Bug: T126617
Bug: T125949
Change-Id: I95fcae8f822e51d9353599c09f1550797e4ad673
This rule ensures that long human-readable wiki names
don't cause horizontal scroll bars in the notifications
popup.
Change-Id: Id0c954d2059aeed875fa2eea7a45537aac4e2e58
The bounding box of where this cursor effect is applied isn't
quite the same as with bundled notifications (which in turn isn't
the same as with normal notifications), but to fix that we need
to normalize the DOM structures of the three types. They
currently differ in the presence/absence of the <a> wrapper
and in how padding and margins are used.
Bug: T138913
Change-Id: I1ed32e0a9deca62b68d08acd0699431ddda8ca44
If we are marking the item as read/unread, we don't want the change
in class to trigger the unseen animation. When that happens, first
remove the 'initiallyUnseen' class (that triggers the animation)
and only then mark the item as read or unread.
Bug: T138522
Change-Id: I05e02518feb1fc166297594053a084718dcb7194
Also add border-box to prevent the circle from appearing
to grow when a border appears.
Bug: T126214
Change-Id: Id5e89ff87759c4ae44851d5ad3061230a0e59ff0
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
Adding up numbers in the front-end is not enough, because it could
be that not all pages are listed (it's a top 10). So get the
total count from the backend.
Change-Id: Ibbc76691ef88333b92132a514fdba3cde3797e10
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
Allow for mark read and mark unread through the side button, and
change its style according to spec in the ticket.
Bug: T126214
Change-Id: I78a93c0545bbe2d7c11a0c62557cd2e97e9d3866
This ensures that the fallback timestamp is used if the list is
still empty. Not doing this causes the wikis in the cross-wiki bundle
to appear in the wrong order. Also, it makes more sense to use the
model as the source of truth regardless.
Bug: T138115
Change-Id: Icbfdc7e7c7f67179e50f0f692aef1a54568265e6
- Remove duplicated counter adjustments.
- Differentiate between all IDs to mark as
read vs. all IDs that represent visible
notifications when adjusting the counter.
Change-Id: I1b3e52a929c6e920e3b782c9ef028539b3db0c99
This is done the quick way by just turning
off a config option. The full cleanup
is in I095704252eaf2f8fe71950a4cfcd42a6fce431ff
Bug: T132525
Change-Id: I5becaa2f91b7eff6ebe4ce3943e86975c844c884
The "Mark all as read" button had margins that made it just a little
bit taller than the header would otherwise be. This pushed the
bottom border of the header and the top border of the first notification
away from each other.
We only need top and right margins on this button, so drop the
bottom and left margins.
Bug: T137778
Change-Id: I8d47d84c79cbdad707b8cbaa8d43187c054755b3
This should have been done from the beginning; the model manager
pulls models by their symbolic names. So far, we've used the source
for that, but that assumes that two modules always have different
sources, and that is absolutely not necessarily the case.
For example, internal local bundles will each be a model, but have
the same ('local') source. They should still be differentiated in
the manager by their names, but the source should state clearly that
it is local.
For this, the models now have "getName" method and the name is
created separately from their source. Items also preserve a
reference to their parent's symbolic name so they can provide
that for items that require the controller to manipulate a specific
model.
Change-Id: I8c39d5d28383d11fb330addce21e07d5c424da6f
In the current bundling system, only the
bundle base is mark as read. It leaves all
the non-base bundled notifications without
a read_timestamp. They would all appear
as read in the new bundling system.
With this change, all notifications in
a bundled are update with a read_timestamp
when the bundle is read.
The implementation of this change is
somewhat temporary as the new bundling
system brings changes to the models
and controller.
Bug: T136368
Change-Id: I70b71d722d8d62cbdd1adc004293030ef900ac94
