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
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 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
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
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
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
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
Make sure we pass the current user to the message, since empty
{{GENDER:|}} doesn't seem to work in PHP.
- Add parameter to documentation
- Add {{GENDER}} syntax to en.json as example
- Add parameter to the message creation
Bug: T144538
Change-Id: Ifc5e3bbe8309cc9ce120b7d61cdc050d7055aacc
Subclasses should not override this. Also fix the return type phpdoc of
getNotificationCountForOutput().
Change-Id: Ia6963794d3a68dca742fe52ac197edf1575bed76
Any class implementing EchoEventPresentationModel and overriding the
getSecondaryLinks method should return an array (while getPrimaryLink
could return a false boolean value).
This change fixes the following errors:
Warning: array_values() expects parameter 1 to be an array or collection
in …/extensions/Echo/includes/formatters/EventPresentationModel.php on line 494
Warning: array_filter() expects parameter 1 to be an array or collection
in …/extensions/Echo/includes/formatters/EventPresentationModel.php on line 494
This is a follow-up for commit b4b59ee4.
Bug: T145229
Change-Id: Ic66ca03b6979472495c9b748093d01f8f097d56a
If a user recieves 'this is your X edit' they should get this notif
regardless of whether the edit they created was deleted. We should
make sure the title is there only for deciding whether or not to
create a link for it; otherwise, the notification will just appear
without a link to the revision.
Change-Id: I00ed4278bb4e15b1e9ddfa2c3af8fad0540fc5f8
This is necessary to preserve backwards compatibility for the API, and
this also fixes the no-JS special page.
Also, fix additional warnings.
Change-Id: Id603b4ab22c69097d5559a756bec72a6ba785661
Allow extensions to add dynamic actions that perform some
API request and display a confirmation message.
Bug: T132975
Change-Id: Ib16d57c3f1a11a9749564c6e2112bf1ca32c55e8
Adds common bundling including messages and icons.
Bundling relates to revision now.
Changed order how notifications are generated. Now errors will
show first, since they are generated last.
Bug: T140224
Change-Id: I1069aeb5523db8710da4e8e21065bf447d031e3c
Adds new notification type and icon for successful mentions.
Complements existing test to consider successful mentions.
Bug: T139623
Change-Id: I7a77b40e8b14c95cadb9023065ee916247feacf9
- Adds global "$wgEchoMentionStatusNotifications"
to activate mention status notifications.
(must be set before extension is loaded)
- Adds notification types and icon for some basic mention
failures.
- Adds failure and stats for anonymous IP.
- Adds check for links to user subpages.
- Adds config var for max mention notifications allowed.
- Bundles notifications.
- Refactors test for the event generation and adds tests
for unknown users, user links with subpages and failures
for too many mentions.
Bug: T136326
Change-Id: I388bdc3714feb9a2865a5ad10dbeabb0a6a09a4f
Followup to I639b9d9906d3ff37021cb9b5ed3cb401354b5bd9
* Remove deprecated formatter
* Log a warning and fail gracefully
when an event type does not support
Echo presentation model.
Bug: T121612
Change-Id: Ic5712c4ce265b6faabce7a4028b4294fe3c73f18
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
This is already done in EditUserTalk-, Mention- and RevertedPresentationModel,
so PageLinked- should be consistent.
Change-Id: I4786406cabab778250d72c7ed92701b940a0a9f7
In the current bundling system, only the
bundle base is mark as read. It leaves all
the non-base bundled notifications without
a read_timestamp. They would all appear
as read in the new bundling system.
With this change, all notifications in
a bundled are update with a read_timestamp
when the bundle is read.
The implementation of this change is
somewhat temporary as the new bundling
system brings changes to the models
and controller.
Bug: T136368
Change-Id: I70b71d722d8d62cbdd1adc004293030ef900ac94
Will only show for new instances, because the information
will be unavailable for old ones.
Bug: T135959
Depends-On: I3d894acaf3d85b790e5034c7d9f76bf94672f445
Change-Id: I04620678dd0ebffb3b1a92a9a0587cb7557d77f4
This was causing warnings in production:
Invalid parameter for message "notification-body-edit-user-talk-with-section": a:1:{s:9:"plaintext";N;}
Change-Id: Ibdea5d899caf446a8c7f811416fdabaa3dccccdd
Formatters based on presentation models for
individual event emails and digest (daily, weekly)
plain text emails.
Bug: T121067
Change-Id: I4eceaf521315adab7429a8a73ffca70ebcddab86
Notifications were being marked as read in response to a click event
in JavaScript, but that causes a jarring effect in the UI, and it's
not reliable (the browser could abort the AJAX request).
Instead, add ?markasread=XYZ to the end of every primary link URL,
where XYZ is the event ID.
Bug: T133975
Depends-On: Icb99d5479836fea25a47451b5a758dd71f642f71
Change-Id: I8047d121584b43e6172463a50ad0e0de5f7fa73c
It doesn't use $this, except to call getWikiTitle(), so make that
static too. This allows us to use it in EchoForeignPresentationModel
without creating a second instance there.
Change-Id: If778db0852de1cbf5c2190ce50ce561745bb3887
They were using different code and different approaches.
I've left getSection() and the code for creating a Title
with a section duplicated for now, and I'll move them
into a trait in the next commit. I wanted to do that
separately because we aren't using traits in this
code base yet.
Change-Id: I56cf745d2cc8a6c43caec08024187de9598cecb8
We ended up double-parsing section titles, which resulted
in strange behavior when the section title was something like
{{tl|infobox}}.
Bug: T132872
Change-Id: I4434624f392cd0e1df39374d45d60f7d83be7161
formatSummary() was first parsing the summary using the
summary parser, then handing off the resulting HTML to
getTextSnippet() which parsed it again with the normal parser.
Bug: T131087
Change-Id: I2724ccb7c23579b3f02dea57d4fc833079169adf
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
Don't try to render if page was deleted, and fix 'extra' parameter
(was breaking message key and thus rendering)
Bug: T129641
Change-Id: I5d0fdfd3921427993211969eb5793f8e9e7667a8
When $adjustLength is false, truncation will only happen
when the string is longer than the limit + the length of
the ellipsis to avoid the case where the ellipsis make
the string longer than the original.
Bug: T121822
Change-Id: I731a3c38b96ede6c6510f64771be0b9662dcba43
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
