Previously, getNotificationCount() only looked at local notifications,
and foreign notifications were added in separately by getMessageCount()
and getAlertCount(). This didn't make any sense and resulted in
counter-intuitive things like I4d49b543.
Instead, add a $global flag to getNotificationCount(). If $global=false,
the local count is returned as before, but if $global=true, the
global count (=local+foreign) is returned. If $global is omitted,
the user's cross-wiki notification preference determines which is returned.
Update getLastUnreadNotificationCount() in the same way, since it had
the same issues.
Also add caching for global counts and timestamps, using a global
memc key.
Bug: T133623
Change-Id: If78bfc710acd91a075771b565cc99f4c302a104d
Replace getAlertEvents and getMessageEvents with
getEventsForSection.
Also, add IDs for linking to sections
Bug: T123018
Change-Id: Ic480320a52a401609d853fc8c75c781b89bb8722
Merge and deploy at the *same time* as:
* BounceHandler - I3c669945080d8e1f67880bd8a31af7f88a70904d
* mediawiki-config - I13817c139967ed9e230cfb0c87c5de66da793c96
Despite claiming to be about categories, $wgEchoDefaultNotificationTypes
was actually configuring both categories and types (which go inside
categories).
For example, 'thank-you-edit' is a type, but 'emailuser' is both
a category and a type (when used as a category, this has special
effects at Special:Preferences).
Since types and categories can and sometimes do have the same names,
this leaves no way to properly and clearly configure them. It also
makes it difficult to document what is going on (as required by
T132127).
Split into three variables:
$wgDefaultNotifyTypeAvailability - Applies unless overriden
$wgNotifyTypeAvailabilityByCategory - By category; this can be and is
displayed at Special:Preferences
$wgNotifyTypeAvailabilityByNotificationType - By type; this cannot
be displayed at Special:Preferences. To avoid confusing the user,
we introduce a restriction (which was previously followed in practice,
AFAICT) that types can only be overridden if the category is not
displayed in preferences.
Otherwise, it can look to the user like a category is on/off, but the
types within might have the opposite state.
Due to this configuration change, this is a breaking change, and needs
coordinated deployments.
This also lays the groundwork for T132127
Also change terminology to consistently use "notify type" for web/email.
It was mixing between that and output format (which unfortunately
sounds like the API format, e.g. 'model').
Bug: T132820
Bug: T132127
Change-Id: I09f39f5fc5f13f3253af9f7819bca81f1601da93
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 assumption currently made that "we only need to add these users
once" is only because of a hack in MediaWikiTestCase that is being
removed in If251739f.
Bug: T132411
Change-Id: I4924ae941b3844b39dd3f44c6986c3bf29b0d62a
There is currently a hard cap of badge display count.
We'll want to be able to request a different count for other purposes:
cleaning up old notifications, for example. We want to keep around a
certain amount of motifications (which is higher than the display count)
so we must be able to query a different count.
Change-Id: Id460fd7f46e397d22da49283b30fd12a6bbb0c9f
This involves:
* Making this value no longer admin-configurable.
* Changing getNotificationCountForOutput to return only a single value
Since there is no + in the formatted value anymore, we can actually
use the same value for both.
This is a B/C break, but hopefully worth it to simplify the method
call.
For now, the excess parameter is just marked unused. It could be
removed at some point if the translations are updated.
This must be merged at the same time as:
* Flow - Ibfa56b1af9e8c56b4c5f900e0d487bc09688b2a2
* MobileFrontend - Ibf784b279d56773a227ff261b75f2b26125bbb63 (well, MF
can be merged first)
* translatewiki - I2a4b6938aed49e4101deb6b9351c43656a863490
Also, change 1 to One/one, per Siebrand on the task. This can easily
be dropped/undone if we don't want it.
Also, remove reference to no-longer-existent notification-page-linked-bundle
Bug: T127288
Change-Id: Iabeaae747f99980c0610d552f6b38f89d940b890
This code is completely useless:
* for format=flyout, the new EchoFlyoutFormatter.php will be run
* and even that one has already been deprecated as it was replaced
by format=model (flyout html is now built in client)
Change-Id: Iea23abb66397ecc4efb575fe33fdbedc5b4e0f70
The existing "html" formatter was used for the special page & is now
superseeded by the new-style "special" formatter. Previous "html"
notifications are no longer used & could even be broken.
Instead of keeping the old "html" formatter around, we should let it
use the new formatter (and eventually just kill that redundant format
in the API)
Change-Id: Ibbd40aafa9eee718b196ad62f6edc99629b263b4
Right now, if certain users should be excluded, that would have
to be part of the user-locators already. This is annoying because
it's hard to write "generic" user locators when you want to exclude
just a couple of people in certain cases.
In Flow, for example, we have user-locators for users watching a
board or topic. We don't want to send the notification to people
that have also been mentioned in that post (they'll get a separate
notification). We could build that exception into those
user-locators, but then we couldn't re-use them in other places...
This basically means we couldn't use EchoUserLocator::locateUsersWatchingTitle,
we would have to roll our own that also excludes mentioned users.
Instead, this lets you add 'user-filters' (that functionality
actually exists already, but is not currently exposed), which
lists users to not send the notification to, even though they could
be in a user-locator.
Bug: T125428
Change-Id: Ifa0e2d3283f57624af4c5ec264f9f66223508e83
Also removes tests for the class.
Bug: T119253
Change-Id: I4c0d7187c2b847297dd0867faecba26185cfba37
Depends-On: Iccafbbdb06711463fee0f30a11326c7771df30e2
Right now, it'll only respond a certain, fixed, amount,
not allowing you to paginate the list.
Note: haven't properly tested all possible cases yet!
Change-Id: I84761b13a1b9203cb8e3fcc80941d739cd28659f
It's basically impossible for DatabaseBase::select() to return false now
that ignoreErrors() is protected. So always return an array so callers
don't have to worry about false.
And remove a test that checked the result if DatabaseBase::select() did
return false.
Change-Id: I9ca8511585403d8c0ec262898ad4e61c2b038d51
This changes the revert notification (special page version) to link
to the contributions page for anonymous (logged out) editors.
It still links to the user page for logged in editors.
Bug: T55564
Change-Id: Ib1f17fb88237b96cda63dd30ed488a8ffd84750e
Push the $wgEchoNotifications dependency to
NotificationFormatter::factory(), and only catch exceptions we're
actually expecting (NotificationFormatter::format()).
And clean up the logging to use structured logging while we're at it.
Change-Id: I7e18c318c5c81b6a38e55f27ef8f604654f10858
The logic to get the URL for an icon was duplicated in the
EmailFormatter and BasicFormatter. It is now in the abstract
NotificationFormatter, which EmailFormatter and BasicFormatter now
use.
Changes in logic:
* Throw an exception if an invalid notification type is provided instead
of a PHP notice
* icons using 'url' may have different ltr/rtl icons
* Throw exception if icon is supposed to have different icons for
ltr/rtl, but doesn't, instead of debug logging
The new function is static so it can be used in EmailFormatter as it
does not inherit from NotificationFormatter.
Bug: T60726
Change-Id: Ia3c01c35f58eed8cc2c039249ab1ec1a80a8abbb
I tried to stick as close to the existing code as possible.
Special:Notifications is slightly different from the overlay,
however. I made it add .mw-echo-unread class for consistency,
but that JS doesn't record seen time (it only loads older
entries), not does the CSS fadeout apply there (it marks
everything as read as soon as it's displayed, so different
behavior from overlay)
PS: I'm not sure about browser compat for the fadeout. But
even if some obscure browsers don't support this, meh. It's
not an "important" feature that can't be missed.
Bug: T94634
Change-Id: Ibb201823fb52ef8a3d5eaa39b0b724ede8d271d1
* Parser generates signature to compare against
* Signature can be overwritten per wiki, in NS_MEDIAWIKI
* Such overwritten default can be different depending on
page the signature is on[1]
* Our comparison signature generation was page-agnostic
(always from Title::newMainPage)
* Signatures didn't match up on own talk pages, where
default signature is different
Also added 2 new tests cases & improved tests by also
setting the page
1: https://en.wikipedia.org/w/index.php?title=MediaWiki%3ASignature&diff=176507985&oldid=176229132
Bug: T78424
Change-Id: Ice151d4d16236a5d1556ef62805b61310c7beb85
Previously, there were a couple of hacks in play.
It was also not picking up ~~~ (signature without timestamp)
And it relied an a nasty regular expression which, although
based on Parser, may some day get out of date.
And it relied heavily on a specific signature format, which
isn't guaranteed (it's an i18n msg)
This patch changes the approach: it will use a very simple
regex to match links, and will send those through Parser to
generate the signature anew. My reasoning is that that should
be exactly the same as what Echo just received (should've
also gone through parser)
Biggest discomfort of this approach is that it's much stricter.
It should still match whatever it generated from a ~~~ or ~~~~,
but no longer the e.g. not-real signatures we were doing in
our tests. Also had to update our tests, because signatures
change depending on anon. So I had to generate all the users.
And fix some of the signature formats used in the tests.
Bug: T75426
Bug: T87852
Bug: T75366
Bug: T78424
Change-Id: Ibeff36397129fdd5d376f3668a23a45f9a014525
