Title fragment isn't supposed to be escaped on input. It gets escaped later,
when getFullURL() gets called on the title. This previously didn't matter much
because Sanitizer::escapeId() doesn't break anything if called repeatedly. However,
now it's deprecated anyway and uses legacy encoding so I need to get rid of it.
Change-Id: I6392604ac0841ae92a21ecb569c9643d7bc6231c
Otherwise, if $list->getValues() contains the number 0,
any non-numerical string will match, because 'foo'==0 is true.
This, in combination with a broken maintenance script that had
inserted 0s into some users' blacklist, broke all notifications
for those users.
Bug: T177825
Change-Id: If8700b4d0de0fdba876eb9d5cc4997e185dfeb3c
Various selectFields() methods were deprecated in MediaWiki core change
Idcfd1556, replaced with getQueryInfo() methods.
Change-Id: I5d62ad76fdb64a9c6efd228f27e9b5f512f17d5e
Depends-On: Idcfd15568489d9f03a7ba4460e96610d33bc4089
User objects haven't been stubbed in awhile, and language objects
aren't being stubbed anymore.
While we're here, swap a few MWException -> InvalidArgumentException
since they're more accurate :)
Change-Id: I7e2f2aa135b024fb653c3ec13181d7015383ff2f
The echo mute list uses user names which are not stable. User ids should be used instead.
Bug: T173475
Change-Id: I947bcf37a8f85aaa105776d368dbd0ab76823aeb
While working on my own Echo notifications for CategoryWatch, I came
across this bug. I was happy to see that someone else identified this
a while back.
Wikitext-to-html production for the body of Echo messages does
not fully qualify urls. This means that links are created pointing
to, for example, "/w/index.php..." instead of
"http://example.com/w/index.php...". Supplying a base URL in the html
for the message fixes this problem.
Bug: T141521
Change-Id: Icfb9f3be58b83d2a441972adb58fef1169169d7c
The following sniffs are failing and were disabled:
* MediaWiki.Files.ClassMatchesFilename.NotMatch
* MediaWiki.Files.ClassMatchesFilename.WrongCase
* MediaWiki.Files.OneClassPerFile.MultipleFound
Change-Id: I7cbf305fae765dbf68df07f84992c2d5ed5486c6
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
This will be used to submit a new article reminder, for a specified date.
The delay is not implemented yet.
Bug: T166973
Bug: T167450
Change-Id: I773bbe98e781957912350c481c850b3263cb1821
The latter doesn't trim(), so add trim() calls in some cases.
User input is trimmed, parsed i18n messages are not.
Change-Id: I933a6a929bf7d3e2d1623ea537227dc8c731cb6f
Includes feature flag, presentation model.
Temporarly hooks to new user creation.
Bug: T165755
Bug: T165754
Change-Id: Ic0a2ca07b0cd1597e5534bb1f3b748beb215ddfc
There was a null-dereference for events without titles.
Also, it should only whitelist their own user talk space, not e.g.
mentions on someone else's user talk space.
Bug: T150419
Bug: T166627
Change-Id: If7d9cad4eb33ce1f1e6b7d86244332ad5dece954
The return value from the method is only suitable for passing to
$db->insert(). To get the inserted ID, you need to call $db->insertId()
even if $db->nextSequenceValue() returned non-null.
Bug: T164900
Change-Id: I466fd372804927b3ad72125c7a69d253bd7a24f8
Only retry lookups if there are multiple DB servers and
changes were made in this request. This same logic is used
in a couple of places in MW core, like WikiPage::loadPageData()
and Revision::newFromConds().
Bug: T164505
Change-Id: If1af363f9687019864b5eaef72ffe0bc824a2223
This patch will fix the notification counts in bundled mention notification
messages. The former method did not work at all due to false assumptions
what the getBundleCount method can be used for.
Since this is in the presentation only wrong messages should be fixed when
deployed
Bug: T164115
Change-Id: If316549a090c2d281a8d612e4985fd556eabc807
In MentionStatusPresentationModel, prefer
extra['failure-type'] to event-type to determine
why the mention was not sent.
Bug: T144614
Change-Id: Id3b55e15a0c1a8f3fee19cbe07983c6e373b309e
There's a lot more that could be done to improve user "rights"
notifications (really user group notifications), but this will do for now.
Bug: T159301
Depends-On: I5d32445f8e5b41599889b8488a2431e7a908f858
Change-Id: I27d52bc5c39219c832bf63a491faa1e421b0c024
Before, secondary icons, such as linked, changes, thanks, and
userSpeechBubble were loaded in mw.echo.ui.icons.less. Now, an
extra icons attribute is passed when the module is loaded, allowing
RLEIM to know which icons to load. If this attribute is left out,
an MWException will be thrown.
Bug: T159394
Change-Id: I9b36a74bcf1da0d1c698845bd067b226fb81ac96
When content is changed and the change contains the signature
of the user, the method checking for reasonable mentions in
that changes did not consider multiple signatures.
The patch fixes that and adds a test for it.
Bug: T154406
Change-Id: I86303f42e97d16c68e3235b0e2d13542ceedf1fe
