This method can return false if getParsedSectionTitle() returns false
Both Language::embedBidi and Language::truncateForVisual return
non-string primitives unchanged if they're passed to them as first
argument.
Ideally the Language methods arguments should be string-typed but
I am not sure how easy that change would be now, so better to
document the possibility here.
Change-Id: I7e2856862d6508ecd1aa57ad99b92942bc4d7bed
Replaced all occurrences of "iconURL" in the extension's repo with
"iconUrl" after spotting a typo in `mw.echo.dm.NotificationItem.js#13`,
"iconUrl" (find the correct "iconURL" in `mw.echo.Controller.js#394` in
the diff). Thankfully the typo was only in the documentation block, but
given the casing of other config object properties like "primaryUrl"
and "secondaryUrl", it would be best to make them all consistent to
prevent any bug that could happen in the future.
Change-Id: I56e6a1d2c7695204b35e767679a27ee22b3fe4bc
This was a mistake in I53c0283, sorry. There are two users involved:
The "agent" is the user (typically an administrator) that made the
user group change, while the "viewing user" is the user for which the
user group was changed. When the "agent" moves the "viewing user"
into a new user group, the "viewing user" is the one that's now
a member of that group. They are what dictates the gender for the
"group-…-member" message.
Is this mistake bad enough for a backport?
Bug: T368249
Change-Id: I4916de2fb171873b625e51ee8823811e0296d323
This affects primarily the message
"notification-header-user-rights-add-only" which is very priminently
seen by every new editor that made their first few edits and gets
promoted to the next user group a few days later. Turns out the code
was just incomplete. All the information about the user and their
gender is already there, it was just not forwarded correctly.
Notice there are two messages:
* "group-…" messages don't have gender support. This is the (ideally)
gender neutral name of the group. Meant to be used as e.g. section
heading for a list of users.
* "group-…-member" is the same with gender support. To be used in all
contexts that are about a single, specific user with known gender.
Which is exactly what's happening here.
Turns out we can even use a neat convenience function from the
Language class that does exactly what we need.
I can't tell why but the array_values is apparently critical.
Originally added via I49b5fe5. It can't hurt so I keep it.
Bug: T368249
Change-Id: I53c028375d77c93f399538fd38aa8f8af30934b0
The duplicated parameter $6 is unused since 2016, see Iabeaae7.
Nothing is left that uses the parameter. I also checked for local
on-wiki overrides via GlobalSearch.
Bug: T368249
Change-Id: I8a5975347756f2fd5f5e065112ddc38d829e89ed
This is a copy-paste mistake from the message directly below.
Happened in Ibe0092a not long ago.
Also add some comments to make it easier to find the places where
seemingly unused messages end being used.
Bug: T368249
Change-Id: I709c0f14978daad8c98f1f8edf52ef28029c6d40
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I3d7a1ffe167b69d3f4ce51d0c248c758e1cdd70c
Most notably:
* Use the much more narrow UserIdentity interface where possible.
* Make array type hints in PHPDocs as specific as possible.
Change-Id: Id189da4028b7874909277881dcf6539169dd13b6
Allows users to send notifications to themselves (T306211). For sending
notifications to others, a new permission is created (echo-create),
assigned only to bots by default. For now, only one user can be notified
in one API request.
If the email flag is set in the API params, the notification is also
sent as an email, provided the user hasn't disabled email notifications
for the "api-triggered" category.
This feature is behind a feature flag. Set $wgEchoEnableApiEvents = true
to use.
Adapted from If0267a38be7d454e3d284d30f93c93a828288dd7.
Co-authored-by: TheresNoTime <starling-ctr@wikimedia.org>
Bug: T58362
Bug: T306211
Change-Id: I94642bff5dcb075cb9db862206d59c19edad9fd1
Many of the Xml::… methods are deprecated. This code here is not
generating XML anyway, but HTML.
Bug: T341775
Change-Id: I69edf4606bc5cb429d48c8188c691b44575e2d93
Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: Iad87245bf8082193be72f7e482f29e9f1bad11fc
Creates a notification type to notify users when their
user page is edited.
Co-authored-by: Kunal Mehta <legoktm@debian.org>
Co-authored-by: Ed Sanders <esanders@wikimedia.org>
Bug: T3876
Change-Id: Ibe0092a96d96f6fa9d93991418b723f3e70e1b75
It would be nice for editors to be able to see the particular edit
that was their 100th, 1000th, etc. This patch changes the link of the
edit count thanks notification to the diff of the edit, rather than the
page the edit was on.
Note that this link will only work for newly created notfications. Past
edit count notification database entries do not store what revision id
the edit was on in the 'echo_events' table, so there is no way to link
to them unless the table is updated.
Bug: T326998
Change-Id: If81fd71ce6f99ad3883a3bfbfbd798270f762d37
This changes the page linked notification to link to the diff of when
the page was changed and removes the "View changes" button.
Bug: T324849
Change-Id: I25a3de3ce5c02be3abbab1d2d2dd1aad8d287cbd
