It doesn't work if every call to cache() returns
a different CachedBagOStuff :')
I found this thanks to log warnings I saw locally:
SQLBagOStuff.WARNING: Duplicate get():
"mediawiki:echo:seen:alert:time:1" fetched 2 times
SQLBagOStuff.WARNING: Duplicate get():
"mediawiki:echo:seen:message:time:1" fetched 2 times
Change-Id: I9a920de88275c1297942b064cc635d5c25424fd2
The comment said "don't validate the username - anon (IP) is fine!"
– but it also allowed invalid names, not just IPs, and those are not
really fine.
Also add more test cases and remove some unused test code.
Bug: T380242
Change-Id: Id98f14a0663f33eb5e45045bcd2df6a1e1f52de6
Why:
* Echo stores agents by their user id or by the name if the user
is not registered. This works for IPs since the "event_agent_ip"
field has limit of 39 bytes (32× [0-9A-F] + 7× colon for IPv6).
* However, it's possible to hold a user identity that is not
an IP address, but the user name has not been or cannot be
registered (e.g., external users). Echo wouldn't validate this
and would attempt to insert the user name into "event_agent_ip",
possibly causing silent truncation and data corruption.
What:
* Do not let events with such agents be saved. For now, log an
error in the production. Wikibase, the only known source of this
problem, has already been fixed.
* In runtime, replace every possibly corrupted user name with
a placeholder to avoid unexpected null values and exceptions
in production.
Bug: T367638
Change-Id: Ic2bd218b10651d13da9e9aea54dd2d668a33d946
Depends-On: I03b4367355dc5a3fc0c14aad5fdf19fbcd0caa3d
Depends-On: I92eb93983e81708b289e9f7d837884d539dade0b
Calling the parent method first means the form has to be built (as
well as various other things) and then it cannot be shown because
of permission and the user is redirected.
This also lead to confusing behavior where some code paths are
reached even though the user cannot actually access the page.
Change-Id: If354d98f9e51acef38cac114a7704d28c148017b
Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: I251cb37401c37242f493816b6f70ab61a64a4c32
Parent class constructor gets type-declaration in 1145328459
Remove simple doc-blocks without further information
Change-Id: I0ab283cd0510d8e85e93752a5ee7d65320a4ec2b
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
Why:
* On wikis with lots of bot activity like Wikidata, there is a large
volume of edits which can potentially create an article-linked
notification. These notifications are now actually rarely sent
because they are disabled for bots (T318523). However, the event
record is always inserted into the database, with no reference to
it, bloating the database.
What:
* Do not unconditionally insert an event into the database when
Event::create is called. Pass it to downstream calls and have
it inserted when it's clear it will actually be needed (i.e.,
a notification is definitely going to be created).
* Pass the event's payload to the job queue instead of requiring
its ID. Introduce Event::newFromArray, which unlike ::loadFromRow
handles ::toDbArray values that haven't been inserted into
the database yet.
* Introduce Event::acquireId which ensures the event has been
inserted prior to returning its ID as well as it does not get
re-inserted.
Bug: T221258
Change-Id: I8b9a99a197d6af2845d85d9e35c6703640f70b91
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
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
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
This reverts commit e8cbb4d662.
Reason for revert: phan dependencies are restored
Depends-On: I0d07c9412bbb63c947255587a88020637e70b80a
Change-Id: Ib6c1709483e4d8518510c4477bf15699cafc1313
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
