It's terrible that in groupbysection mode, you still have to pass
messageunreadfirst and alertunreadfirst separately, but at least
this way the unreadfirst feature is available at all in the
non-grouped mode.
Change-Id: Ifb0707be484bda8e33810c888bae1d008cac2d9f
API requests with notgroupbysection disabled but notsection set
to 'alert' would return foreign notification bundles for both
alerts and messages, separately.
The frontend always pasess notgroupbysection=1 in practice because
notmessageunreadfirst=1 doesn't work without it; but regardless of
that, the API module shouldn't return a foreign notification bundle
for messages when only alerts are requested.
Change-Id: I9fa6d1411a8c121591ce6dd75ee8052bcdcb478b
Using wiki names in the header is problematic because the messages
we were using weren't designed to be used in a sentence, only in headings.
This removes the wiki names from the sentence in the header, and
instead puts a comma-separated list (with "and") of wikis in the body.
The messages keep $3 and $4 for backwards compatibility, so translations
of the form "from Commons and 2 other wikis" will keep working.
Bug: T121936
Change-Id: Ideeba794e260b3c388fa29226b53197c050162ef
It wasn't meant to be there, and flow-mention doesn't have it either.
We also don't have any other notification types with
three prioritized secondary links.
Bug: T125949
Change-Id: Icbffa185b1116b1a6beb9bb3585339fdf7e82cdd
The approach here is to use $msg->escaped() to
remove all markup and then replace new lines
with a single space.
Bug: T128062
Change-Id: I1d5a6e57fbae9b6a441671beff1c60720b9445d5
Some notifications return relative urls in their
primary or secondary links. This change makes those
urls absolute so they point to the right wiki
when viewed from another wiki (cross-wiki notifications).
Bug: T125738
Bug: T127697
Change-Id: Ib65337430eb2484f9491668a9998deef70589fb1
It used to be like this, but in order to get the messages badge to show
in the correct circumstances, I had to know if the user had ever had
foreign messages before & I also needed euw_messages_ts even if those
messages had already been read.
Now that we're unconditionally showing messages, we no longer need these
0-value rows.
Bug: T127731
Change-Id: I1fc13bf0e5133ae39224f66d1b5a59c769bfcee2
Current situation: cross-wiki can be enabled on certain wikis &
disabled on others.
Code used to check if cross-wiki was enabled before fetching the
status of unread messages on foreign wikis. However, it would then
write that result to a shared memcached key.
The cross-wiki check should not happen before data is stored to
cache: what is stored should always be for all wikis. Only when
we fetch it, should we check if cross-wiki is enabled. And if it's
not, we can't use the cross-wiki data - we have to hack around it
ourselves...
Bug: T124372
Change-Id: I3d3d54fc3cbfbf73b51e97acfd8d355dd0cea36d
when the subject line is left with the default
generated value, we take the begining of the
email content to add a preview in the
notification.
Bug: T121831
Change-Id: Ib7c646f6709c7100ef51186f84fe14807d6a211a
Objects can be different instances (and for User, they can contain
very different data) in which case they wouldn't be recognized even
if they were the same user.
Let's find by ID instead.
Bug: T124803
Change-Id: Ia166fd4190f264354cea83d98047c62c7e0714ea
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
