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
Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: I251cb37401c37242f493816b6f70ab61a64a4c32
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
There is no guarantee the MediaWikiServices instance is still valid.
Other tests can reset it.
Bug: T368390
Change-Id: I92de60b2ba5fb66af957a800ce85773db58303cc
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 is much less confusing for certain IDEs. Without the leading
backslash it looks like a relative patch, but isn't actually one.
Change-Id: I9c9f41869ea0ed063a67f8e65807833d1b3dba2b
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
To match the return type documentation of IReadableDatabase::select
Also fix a default value for IReadableDatabase::selectRowCount
Change-Id: I510bd261b64b5c2cef227c081a2fe34801f54121
Remove check for false from IDatabase::select as this is not possible
A DBQueryError is thrown (documented since efda8cd3 / I056b7148)
Change-Id: I465a9158aa6430e7ff8a5a83fe55c5944315aa40
UpdateQueryBuilder does not return a value,
removed the return value from the functions as well,
deprecated since 1.33
Change-Id: I3b934a5e6d5a53c07ec5233da00d9f53ba7bae92
Deprecated in T342301 in v1.41. This is now tracked
automatically. The variable can be safely deleted.
Change-Id: I3864ee85e8b0ff74385eee88018a37f61927f5ef
Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: Iad87245bf8082193be72f7e482f29e9f1bad11fc
User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Ic3e56c6e2ec606bbecbd630d8ad96d111cab24d3
Use
$this->getServiceContainer()
instead of
MediaWikiServices::getInstance()
in maintenance and tests.
Change-Id: I845e8f083b19da093166d6551683f2013eec7bb1
- Remove set of $wgDiff, not used in core and seems not needed
- Avoid array_keys on foreach
- Save settings directly by UserOptionsManager for the fresh user
- Combine calls to overrideConfigValue into one
- Referer core config via MainConfigNames
- Remove unneeded reset after overrideConfigValues, get reset there
- Reset specific service and not all
Change-Id: Ia00efae85e17dfac1768b12b35f44eb834f879ec
In EventMapperTest, suppress notifications created by calling
getExistingTestPage. So far, this test only worked because the existing
test page is created in addCoreDBData (and not inside the test), but
this will no longer be the case after core change
I308617427309815062d54c14f3438cab31b08a73. Clear the PageSaveComplete
hook handlers to prevent that.
DiscussionParser has a static cache of revision data that can become
stale when data is deleted between tests (because revision IDs can be
reassigned to different pages, similar to T344124). This cache seems
needed, and converting the class to a service seems hard, so add the
page title to the cache key to try and avoid collisions. This can still
break if two tests are using the same page, which is hopefully quite
unlikely.
Change-Id: Ic4cbd8ff424e1260544ff9754e0c89dd4bb2f733
Singletons are bad, amongst other reasons, because they're never reset
in tests. They can therefore occasionally cause test failures if the
cached data stored in one of these singletons becomes stale.
As noted on the task, ideally these two classes shouldn't exist at all,
and core should be responsible for caching the information it deems
expensive to compute.
As a temporary (TM) workaround, make both classes actual services, so
that the setUp/tearDown logic in MediaWikiIntegrationTestCase can
properly reset them between tests.
Dependencies are intentionally not being injected, precisely because
these classes should just be deleted, not improved.
Bug: T344124
Change-Id: I58b8d9610f9447468235b94d25732528ab6acce6
The test was assuming that the ID 1 belongs to a user other than the one
being created in the test. This is not necessarily the case, so make it
use an ID that is guaranteed to be different.
Also rename the test fail to avoid a PHPUnit deprecation of test class
name not matching file name.
Bug: T342428
Change-Id: Ied1869e380b023c1a726a5be610e1de1b68c78c0
