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
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
- 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
When the base of a bundle cannot be rendered
(canRender() returns false), the bundled items still
have to be rendered and potentially marked-as-read as well.
If we don't do this, the base is filtered out, marked as read,
the counter goes down by 1 and the bundled notifications are ignored.
On the next query a new base is selected, filtered out, etc.
So if a bundle of 10 notifications cannot be rendered because it's
10 new topics on a deleted flow board, the flyout has to be opened
10 times for the counter to finally be 0.
Change-Id: I06962b25e36802ef00278e2bc70d5377b5874695
When requesting notifications, the 'continue' value used
for pagination is only included if there is more
notifications than requested. When some are filtered out,
there is less notifications and no 'continue' value,
which leads to no pagination at all on the special page.
Change-Id: I1a13d2a343f4e60489e2a6a0474c97664ed00d46
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
Like count, it is available both grouped by section and ungrouped
(top-level).
Unlike count, the top-level still has both sections (but with the
string 'seenTime' at the root), and if groupbysection is used,
it will not also have top-level (since it would be redundant).
Example output at T139993
It will be false or omitted if there is no seen time, depending
on JSON format version (2+ is false).
Bug: T139993
Change-Id: I9f4f9df69203204b56002afa1be6ed2336c33898
Followup to I639b9d9906d3ff37021cb9b5ed3cb401354b5bd9
* Remove deprecated formatter
* Log a warning and fail gracefully
when an event type does not support
Echo presentation model.
Bug: T121612
Change-Id: Ic5712c4ce265b6faabce7a4028b4294fe3c73f18
Check it for both $wgUser and $this->user because they
could theoretically be different.
Bug: T139665
Change-Id: I59cb4f0122a9fccb32ca165fda065dee2467b1da
If we have a central ID, in theory it should not trigger
CA failures when getting a token. However, it is, so maybe:
* This is the wrong way of checking attached-ness.
* It is somehow losing the central ID later.
or something else is going on.
Bug: T140144
Bug: T119736
Change-Id: I71c6f121a728e503aa9d62778e64c650cd8d46af
Attempting to get a CentralAuth token for an unattached
user (or a user mid-attachment) throws an exception.
Bug: T119736
Change-Id: I2a34754f55b952f5bcd4da6c6f89a32ebc29ecf1
When trying to find the max timestamp of all
notifications in one source or the max timestamp
between all the sources, check for empty array
to avoid "Warning: max(): Array must contain at
least one element...".
Bug: T139529
Change-Id: I0bf04ded40872c1c7a0cd3a9a62bc789814f5419
Launch JS version of Special:Notifications even of the
user doesn't have any local notifications.
Bug: T139512
Change-Id: Ia01a57de307b0d7da6a7d81ec8ee32d02ccc1887
This should prevent fatals in the sort-by-timestamp code
farther down, and also prevent incorrect output.
Bug: T139112
Change-Id: I6480b2e751594ba3392322f40e950f95ae702104
Use foreign source reported notifications count
instead of counting the actual objects.
Counting objects is wrong because of bundles
that are 1 object but represent multiple notifications.
Bug: T138888
Change-Id: Ib63efc1e33af8f4364a7ba11a0dc3ff820f0a03c
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
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
Adds $wgEchoSectionTransition and $wgEchoBundleTransition.
If either of these settings is enabled, we will disbelieve
the alert/message counts in the euw table and obtain them
using server-side cross-wiki API queries instead.
This affects both ApiEchoNotifications (for generating the cross-wiki
summary entry) and the count and timestamp computation in NotifUser.
In bundle transition mode, we trust that notifications are classified
correctly between alerts and messages, but we don't trust the
counts in the table. In section transition mode, we trust that
the sum of the alert and message counts is the correct count,
but we don't trust the alert and message counts individually.
If both modes are enabled, we mistrust anything that's mistrusted
by either mode and only trust what's trusted by both modes.
In any event, we do trust that only the wikis with rows in the
euw table have unread notifications.
Bug: T132954
Change-Id: Ibcc8ac102dac3cf06916d67427b42457fdb93db6
This is already done in EditUserTalk-, Mention- and RevertedPresentationModel,
so PageLinked- should be consistent.
Change-Id: I4786406cabab778250d72c7ed92701b940a0a9f7
Better idea: invalidate caches in this script, and write
a separate script to recompute existing euw rows.
This reverts commit c83af257d2.
Change-Id: I57bccfb726eada646cb318206d9091a20d59dcf5
This causes it to update the notification count cache as well.
Should we perhaps rename it to recacheNotificationCounts.php?
Bug: T132954
Change-Id: I540c4296f4fbadcf2267d77b53f71ee5c2eb8b52
This script was supposed to be run in production in 2013, but that
never happened. It was also never added to update.php.
* Use makeTitleSafe instead of newFromText, for correctness
* Fetch the columns that the update generator needs
* Replace wrapper for private method with closure
* Make the maintenance script logged
Bug: T136427
Bug: T50059
Change-Id: I6c2972120189f035483b5ca49610c008c4ba2c88
