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
get_debug_type() does the same thing but better (spelling type names
in the same way as in type declarations, and including names of
object classes and resource types). It was added in PHP 8, but the
symfony/polyfill-php80 package provides it while we still support 7.4.
Also remove uses of get_class() where the new method already provides
the same information.
For reference:
https://www.php.net/manual/en/function.get-debug-type.phphttps://www.php.net/manual/en/function.gettype.php
Change-Id: I54c2bf287b185e2526b0a8556166fd62182b2235
@private usually means "cannot be used outside of this class". But
this is used. I assume it's meant to be @internal as in "internal to
this codebase".
Change-Id: I9326e17f706af336ea0d4b7c0af95330ed575810
Before this patch, middle-clicking notifications would still mark them
as read, but the user would only find out upon closing and re-opening
the notification tray or reloading the page.
Bug: T340179
Change-Id: Ic29af0c70354087cf5f783b5a7370241a86b4bf3
The current code uses deprecated TitleLinksTable::getTitleArray and that
is also using Title::newFromPageReference to get Title objects,
so performance issues or more memory usage are not expected.
Change-Id: I25d047ceb707837009e0a703693ebc2f49fc0ba9
`groupItems[ i ].id` is of type number, and using the spread operator
on it results in a type error. This prevented users from marking
multiple cross-wiki notifications as read, with the associated button.
Bug: T368643
Change-Id: I53d404445956de288aeda8fbfe1bdd1256214839
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
