This allows us to link to the right section when the section
title contains templates or magic words.
* Add getParsedSectionTitle()
* Use it in getTitleWithSection()
** Stop using Parser::guessSectionNameFromWikiText() because it
wants preprocessed wikitext, not fully parsed and stripped text
* Move getTruncatedSectionTitle() from EventPresentationModel to
PresentationModelSectionTrait and make it use getParsedSectionTitle()
Bug: T134216
Change-Id: I877ff6b0ce4e64400f6e5f6284ae47a11cd4335b
This change was made to direct users to the added/removed group.
Notification about the change in the user's right will route the user
to a page about the group.
Bug: T55860
Change-Id: Iff5f4d38ca2cc479c269ef736a7fd957959a03dc
We would generate things like #Foo_.5B.5Bbar.5D.5D
instead of #Foo_bar . Unfortunately this doesn't
fix section titles with templates / magic words
in them, because those are parsed at notification render
time instead of at notification generation time.
Bug: T134216
Change-Id: Ia171324a4a616c956ab08fcff38293f18dc765fa
Whether we estimate or not, the actual stored count should always be
normalized within the range of 0-cap. Estimation should always skip if
the current count is at the cap; in that case, the count can only be
changed when we get the value from the API through setCount() (used
when the value is known, rather than estimated.)
Change-Id: Ie8b81a4433e8254ee0e90f59e5b25d727158eecf
This can be called on GET requests, like when visiting Special:Notifications,
and also from getTime() on a cache miss. Defer the write to the real
cache, but update the in-memory cache immediately.
Bug: T146492
Change-Id: I24db223ded9508942dc0ef1abf55952e98f444d0
It was always set to 0, and we were using the old (pre-2015)
get() interface so it wouldn't have worked anyway.
Change-Id: Ie92b223a485a5d9d256d2dc69d4ff3807e838878
Bonus: remove documentation for nonexistent parameter for setTime().
Only used in external.js to render a simple link. These methods
don't have a regular description and as such the link renders
effectively the same way in the same place without `@source`.
Change-Id: I83cd524b6b53e67c5c2d18258c804ebd49a29b74
- Make sure that even if internal values of the array are null,
the end-result is a valid array (with sequential keys)
- Verify that the API sent the UI an actual array, and if not,
output an error to the console.
Bug: T145825
Change-Id: Ibdf17c58fe88e3e2547dde62cd4d3d06e089cbc8
This transforms seenTime concept to a global property for all wikis
and sources, and updates the global seen time on opening the popup.
Bug: T134855
Change-Id: I67bcc4b346237317c7a9204dd43cd0e9ee02792f
Also, make sure that the bundle follows the same behavior as the
xwiki bundle, where if it does not have a primary link, the 'click'
event triggers the 'expand' action.
Bug: T145902
Change-Id: I456bf76a7bd531ffcad5462708f37cd54d8af99d
When the special page is loaded, all notifications should be marked
as seen for both the no-js and JS versions.
Bug: T134855
Change-Id: I053ce07ca26a858fd42c9d070b7dce73cc161e4b
Although we generally use getViewingUserForGender, these messages
are UI and in user language, so we should change the flag anyway.
getViewingUserForGender is essential for messages that are used
in batch jobs. Some messages technically don't require it, though
it's probably best to be consistent anyway.
Bug: T144538
Change-Id: I7b57777ab93b5752165c7bdd85fa5ce66b294b22
This sends out a notification when a user gets mentioned in a change as
long as a signature is added in the same section.
Bug: T138938
Change-Id: Ie183fbb8150bd9451a5b0a9fea0227e3241b26a0
Has bugs, and will likely cause deployment problems.
This'll need to be reverted in wmf.19 at least
until we fix it up.
This reverts commit 00e0b9f45d.
Change-Id: Ia9d220ebcb607f96dee6bc856755305ed8501fcc
Some of the counts are capped (wiki counts) and some are not (page
counts) - so we are adding a config option ('isCapped') to the
widget to make sure that capped numbers appear with the proper
i18n message ('99+' in English) and non-capped numbers appear
as-is.
Bug: T144707
Change-Id: I7332e7f5108621d0bd403edefe4feacca44b1f88
This follows the generalization we made in the back-end and allows
us to always use the same method to get capped notification count
in the display.
Bug: T144707
Change-Id: I4d7f406b05a195972dca0d2088bde2ff739d313d
