Migrate away from the Title object, use
TitleParser::parseTitle() which returns a
TitleValue which is enough. Will be followed by
switching UserDefTest to a unit test, but in a separate
commit.
Change-Id: Ia756964861c4e0f3edea89f6beec2643243ca741
Maintain the existing behavior for creating based on a user
id or name that does not correspond to an existing user:
* if creating a User object based on the id 0, User::loadFromId()
will load the defaults with the name being set to false, and
User::getName() will convert that false to the ip of the current
request. We probably don't want UserDef to be doing that, but
this behavior should be changed separately - at the moment
we are just matching the existing behavior (see the prior commit
which adds tests to confirm the behavior isn't changing)
* if creating a User object based on an id that cannot be found
in the database, User::loadFromDatabase() will load the same
defaults, *except* that it will set the user name to "Unknown user"
* if creating a User object based on a name, User::getId() will,
if the id isn't already known, return 0 if the name matches
UserNameUtils::isIP() or ExternalUserNames::isExternal(). However,
the User object is currently only created based on a name after
passing an ExternalUserNames check, and the creation with
RIGOR_VALID prevents it from being an ip. Thus, the existing
code will call User::load(), which will check the database or
fallback to 0 if the user does not exist.
When creating a User from an id that does not exist, User::getId()
will return that id, until after the object tries to fully load,
after which it'll return 0 for the id. Since we cannot replicate
this with UserIdentity (switching the id to 0 only after getName()
is called for the first time) we set the id to always be 0, which
is more accurate. This is the only change in behavior.
We will remove the use of the context ip in a follow-up that will
switch to using "Unknown user" instead.
Accordingly, we will use a UserIdentityLookup as well as
manual construction of UserIdentityValue objects to match this
behavior.
Bug: T288311
Change-Id: Ida80c5d04d721fafa8d66f656dbd346c6cf643eb
This helps phan to detect unreachable code and also impossible types
after the functions.
It helps phan to avoid false positives for array keys
when the keys are checked before
Bug: T240141
Change-Id: I895f70e82b3053a46cd44135b15437e6f82a07b2
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
The mandatory Unicode NFC normalization on API parameters was causing
spurious dirty diffs in VisualEditor/DiscussionTools when editors used
HTML entities to encode non-NFC codepoints, like  . Although
wikitext is (ought to be!) in NFC form, the output HTML may not be,
due to explicit entities in the wikitext.
This type is used in VisualEditor change
I0d34c9a01f1132c2616ed3392ea40d8b73e15325 to prevent Parsoid HTML from
being corrupted when it is round-tripped.
Bug: T266140
Change-Id: I2e78e660ba1867744e34eda7d00ea527ec016b71
- Begin injecting services into UserDef to support
unit tests.
- Replace static User class functions with
UserFactory functions.
Bug: T259145
Bug: T257464
Change-Id: Iccc0c39e013679f15f2e62738c56df09ba56c494
This commit also changes ApiWatch to make use of the new parameter type.
Other APIs will be updated to use it in a separate patch (T248196).
In doing this, we are for the first using logic within a TypeDef outside
the API. This seems acceptable given TypeDefs chiefly appear to serve as
a validation method, with otherwise no particular logic tied to the
concept of APIs.
wfIsInfinity() now uses ExpiryDef::INFINITY_VALS
Bug: T248508
Change-Id: If8f0df059eafb73ec9f39cc076b3a9ce2412d60a
ApiStructureTest has a lot of logic for validating Action API settings
arrays during CI. Some of that logic should be part of ParamValidator
instead.
Bug: T242887
Change-Id: I3c3d23e38456de19179ae3e5855397316b6e4c40
Depends-On: I04de72d731b94468d8a12b35df67f359382b3742
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
