There are about 200 of such generic "array" type hints in this code base,
the majority in @param tags. I started with what I found most relevant:
@var and @return tags. I might continue working on this later, but
wanted to stop for now to keep this patch moderately small.
Change-Id: Iff0d9590a794ae0f885466ef6bb336b0b42a6cd3
The special page is only a MessageLocalizer, not a IContextSource.
Its implements all methods of IContextSource, but are delegated to the
underlayed IContextSource. So pass it directly make phan happy, while
the current code works as expected
Change-Id: Ia9d83f2f71a466a2ba74540f96f165c96fb7ca00
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.MissingCovers.MissingCovers
Change-Id: I2a48e5c27a7307b3982d11875180fc11f2a125d9
Currently, the 'Mark all as read' button exists only for JS users.
This patch adds the button for no-JS users as well.
Bug: T96061
Change-Id: I1a62c56306597209540ffd694c8fb7b2a92885c9
'version' was missing, making the event invalid, causing it to
not reach the database.
Factor out this field to logEvent
Bug: T121939
Change-Id: I9e4bb5574d69495cb5f53830047c68104c6ad10f
Adds a check before logging a visit to Special:Notifications
added in Icfe63fb8daa8e8fba029e22b4de3e4f65517c448
Bug: T143092
Change-Id: I9e58ba35eef6a25a78e96a76facc04819cef37da
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
Launch JS version of Special:Notifications even of the
user doesn't have any local notifications.
Bug: T139512
Change-Id: Ia01a57de307b0d7da6a7d81ec8ee32d02ccc1887
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
There was quite a small link under the main title in Special:Notifications
which pointed to a related help page. Now the OutputPage::addHelpLink()
method is used which moves this link to the upper right corner and allows
configuring this on-wiki (instead of LocalSettings.php or so).
Bug: T101057
Change-Id: Ib4aecee8006b8d71bb3cd86f1d4ebdfee9080870
Allow marking notifications as read per 'section' (days) in the
Special:Notifications page.
Bug: T115528
Bug: T134204
Change-Id: I7324a2c693aa92b9327cf8ff98f125293d5fba10
Replace getAlertEvents and getMessageEvents with
getEventsForSection.
Also, add IDs for linking to sections
Bug: T123018
Change-Id: Ic480320a52a401609d853fc8c75c781b89bb8722
This provides a simple unlisted special page,
Special:DisplayNotificationsConfiguration, to document how the
notifications are structured and configured. It shows:
* Which types are in each category
* Which notify types (web/email) can be enabled for each category
* Which notify types are mandatory for each category
* Which notify types are enabled by default:
** For existing users
** For new users
Bug: T132127
Change-Id: I25b447a69a7c984941dfd703345d7977c0000bfe
Added code to redirect the user and display a short message informing
them of the need to login.
Bug: T118873
Change-Id: I2145bc1502dbd19d660302d9f19e0d4a2ad5ad50
I'm not really sure where to stick the primary link. I could wrap the
entire notification in a <a> tag, but all the text becomes ugly (I
suppose we could hack around it with CSS?). For now I just added it
before all the secondary links.
Change-Id: I4f6add9ecfb367660d1a6346825382ad415bdb77
Since EchoEventPresentationModel::canRender can reject notifications,
its result should no longer be used for infinite scroll.
Current code checks if the amount of to-be-rendered data exceeds what
we need to display, but if we reject some notifications that may no
longer be the case, even though there is more data still.
Change-Id: I3e5f8c2d1fc0c63db7b277324c96af043689ddce
