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
