Edits from temporary accounts are considered anonymous edits.
ApiQueryRecentChanges doesn't correctly reflect this and needs to be
updated to correctly return temporary account edits as anonymous (and
similarly, not to return them when requesting !anon)
- Update the anon|!anon query to accomodate temporary accounts
Bug: T370803
Change-Id: Ica5225422ea53d2aa3a84b86d9c2f14832a34ed4
Why:
- Using TempUserConfig is more flexible as it doesn't require us to know
about the internal details of the AutoCreateTempUser config object
What:
- Use TempUserConfig service instead of loading the AutoCreateTempUser
object
- Remove properties from ApiQuerySiteInfo that don't already have
getters. If someone has a need for more this information to be exposed
in ApiQuerySiteInfo, they can be added in a separate patch
- This seems compatible with the goals of T335532 which was about
making it possible to discover via the API if an action would result
in a temp account
- Implement __toString for Pattern, so that it can be used in
ApiQuerySiteInfo
Bug: T335532
Change-Id: Ica84b3e9b9865b8b83a9e9e513c99cd2e47661c9
Why:
* ApiQueryBase subclasses may define a ::isWriteMode override, as
the API call may need to write to the DB.
** This is the case for the CheckUser extension, where the
'checkuser' API creates a log entry that allows users to audit
usage of the API.
* ApiQuery currently does not define a implementation of
::isWriteMode, which means that the definitions by any class
that extends ApiQueryBase currently do nothing.
* ApiQuery::isWriteMode should be defined and work in a similar
way to ApiQuery::isReadMode, so that subclasses of ApiQueryBase
can have their definitions of ::isWriteMode respected.
What:
* Define ApiQuery::isWriteMode in a similar way to how ApiQuery
::isReadMode is written, but also inspecting the modules that
are used through the 'list' and 'prop' params.
* Add tests for ApiQuery::isWriteMode.
Bug: T361951
Change-Id: Idf1c8f95df58a861404e0c89507c885ec4554793
Why
* ApiQueryWatchList allows filtering anon users or not-anon users.
It is not obvious wether temporary users should be considered
anon for these purposes.
* The equivalent filters in recent changes group temporary users
with anonymous users (T343322).
* Since ApiQueryWatchlist queries the recentchanges table, and
shares many filters with recent changes, it makes sense to
filter the same way in both, and therefore to group temporary
users with anonymous users.
What
* Update queries in WatchedItemQueryService to group temporary
users with anonymous users for FILTER_ANON and FILTER_NOT_ANON.
* Don't change the 'anon' flag, because the other APIs flag
temporary users with anon=false.
* Instead add a 'temp' flag for temporary users.
Bug: T358693
Change-Id: I4cd3a4d0c5f4f488933cf3f06dee62a9beb85440
Why:
* The ApiQueryContributors API description says that it returns
'the list of logged-in contributors' for given pages in the API
summary text.
* When temporary accounts are enabled, this list will include both
named and temporary accounts. As such, the message needs to be
updated to make this clear for users of the API on a wiki which
has temporary accounts enabled.
What:
* Add 'apihelp-query+contributors-summary-tempusers-enabled'
which is shown instead of the existing summary message for the
API if TempUserConfig::isEnabled returns true.
* Update existing mention of 'anonymous' with 'logged-out' to
per https://w.wiki/9Ji$ in the existing summary message.
* Update the existing message documentation for the summary message
to link to this new message to make it easier for translators.
* Test the newly added PHP code.
Bug: T341228
Change-Id: Id1bd597e068cb3aa946c94686ca6fa39ef1df89f
Temporary accounts are now distinct from users or anonymous.
Add a flag to reflect that to:
- ApiQueryImageInfo
- ApiQueryLogEvents
- ApiQueryRecentChanges
- ApiQueryRevisionsBase
Bug: T351636
Change-Id: I7986dea5ccd0dc942bf133040c4ac715487f29b9
With multiblocks the user might be hidden even if bl_deleted=0 in the
block row being formatted.
So:
* Add a subquery with a second block_target/block table which determines
whether the user is deleted.
* When formatting each row, redact the name if it is deleted and the
authority does not have permission to see it.
* Add a parameter to show which block is the one responsible for
deleting the user.
* Similarly add a subquery in ApiQueryBlocks.
Change-Id: Id9900397618e1f626802ada6fe4ee4ad10f32495
Support migration stages when reading and writing blocks.
I tried to set it up for an easy next stage, in which support for the
old schema is removed. I tried to avoid factoring out of shared code
between the two schemas, so that the old schema cases can simply be
deleted without the need to revert unnecessary abstractions.
However, I added HideUserUtils to factor out ipb_deleted queries. Code
review showed that this was already quite complex, with multiple
approaches to the problem, so it benefits from refactoring even without
the schema abstraction.
HideUserUtils is a service rather than a standalone class to support
unit tests, since unit tests do not allow global config access. When
the migration stage config is removed, it will be a service with no
constructor parameters -- an unnecessary abstraction which should
ideally be resolved at that time.
When interpreting result rows, it is possible to share code by using
field aliases. But when constructing WHERE conditions, the actual field
names need to be used, so the migration is more intrusive in
ApiQueryBlocks and SpecialBlockList, where complex conditions are used.
Bug: T346293
Bug: T51504
Bug: T349883
Change-Id: I408acf7a57b0100fe18c455fc13141277a598925
When temp users are enabled, logged-out authority may not have the
permission to perform some action, but the user (as in, the person)
may still be able to perform it through the magic of having a temp
user created for them.
Bug: T350039
Change-Id: I5e776d670f0d487346191fa99596dc5d6809a414
Remove hardcoded "Main Page" and use whatever the main page of
the wiki is. Many wikis have their main page in a different
title than the default or even in a different namespace entirely.
With the hardcoded title this produces broken/redlink for the doc
examples and makes it overall less useful.
Most typical examples; Mediawiki.org itself, Wikidata.org, etc.
Bug: T235207
Change-Id: Ia9eee76544cad153166dd5a2eb8e8c1bf3a38b74
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: Ie78be1c614985d7c2964156e454cc9266515dc18
This adds metrics for individual query modules, to break down
the timing currently lumped together in api.query.executeTiming.
This will allow us to track repsonse latency for individual query
modules on https://grafana.wikimedia.org/d/000000002/api-backend-summary
Change-Id: I590fd2aff231789d0b7d31403a5222531f2b458d
Inject TitleFormatter and TitleFactory to improve the best case
(getGoodPages) to avoid calling the factory there instead of using
Title::getPrefixedText after calling factory
Bug: T339384
Change-Id: I21cf9b738cfdb1a418c10e48ec834efefccb6ab7
Both deprecated in 1.39 and hard-deprecated. Unused in production and
allow us to clean up dependency of ApiQuery to LB.
Depends-On: Ia94618b7f58fcca72e903fd2e2e9f0aaa501ac24
Change-Id: Ie0322e5346b94932a2eddc0b7aad5a384768b888
Deprecate 'preload', which only supported one way of generating
preloaded content, and was confused about empty string and null.
Bug: T45683
Change-Id: Ie9f123920b69e41a186bc1c1c5db1bc0a6092a75
For pst on parse/compare/editstash/(all)revisions/(all)deletedrevisions
Do not show the IP when IP masking is enabled,
instead show a previous aquired temp name or a placeholder on preview.
MediaWiki itself used this for the ajax preview on GUI's action=edit
Cannot acquire a new unsaved temp user as api parse does not persist
the global session (each request results in a new id)
and it would require a db write on a read request.
Bug: T331397
Change-Id: I74bb4d655f371bd99e3b618d1a0ac45d730c746c
action=query&prop=info&intestactions=...:
Add &intestactionsautocreate=1 to also check whether the actions
would result in a creation of a temporary user account.
action=query&meta=siteinfo:
Add &siprop=autocreatetempuser to output the configuration
of temporary user accounts.
Bug: T335532
Change-Id: I62b4bb630decac92cbb8c7ddf00307df0dadb516
@note: Deprecated SearchEngine::getNearMatcher and ::getDefaultMatcher()
and begin using the new interfaces. Renamed SearchNearMatcher to depict
what it really does like TitleMatcher when searching.
Also, I pulled out SpecialSearchTestMockResultSet class to a separate
file.
Change-Id: I09990e9f263c075a6ab137ee5bcb7285359f057c
The Rdbms library already takes care of caching and re-using connections
nowdays. Perhaps in a past where DBConnRef was less common or not
yet created this made sense, but we've now adopted that universally.
I don't know of a current use case for WMF, given the removal of
non-vertical query groups in T263127 (e.g. we keep "api" for all API
traffic, but not e.g. something individual classes would change).
For now I've documented that in someone does run into this, perhaps
in third-party code, that we recommend instead to override getDB()
instead of relying on this central mechanism. E.g. overriddet getDB()
to return `wfGetDB(DB_REPLICA,'mygroup')`.
Bug: T263127
Change-Id: I4c3cc7868f1f4210ee655541eb6a45705c643c70
Even the service does not long stay in that classes,
it should be injected to avoid global state
Bug: T304780
Change-Id: Ib488037f5a6966ab61042ed3cd889ddc50f1ba8e
Getting only the gender option from the UserOptionsLookup is expensive,
because each option results in one query to load all options.
The GenderCache allows for prefilling the gender for multiple
users and results in only one query. That can make a difference if
multiple user names are requested.
Change-Id: Id954a636452d5729eb3b8050db4a0068bf02c9ed
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
The parameter is using the UserDef validation,
which provides all this features
Also all params are guarded to be set in the $params array after
extractRequestParams(), no need to use isset on $params.
Make explicit that empty bkusers= or bkids= are ignored,
instead using the implicit check in addWhereFld.
Doing nothing when requesting nothing would be a breaking change.
Change-Id: I3602412874b1b3a954037d95ad7cefbe865e3893
CommentParser:
* Move comment formatting backend from Linker to a CommentParser service.
Allow link existence and file existence to be batched.
* Rename $local to $samePage since I think that is clearer.
* Rename $title to $selfLinkTarget since it was unclear what the title
was used for.
* Rename the "autocomment" concept to "section link" in public
interfaces, although the old term remains in CSS classes.
* Keep unsafe HTML pass-through in separate "unsafe" methods, for easier
static analysis and code review.
CommentFormatter:
* Add CommentFormatter and RowCommentFormatter services as a usable
frontend for comment batches, and to replace the Linker static methods.
* Provide fluent and parametric interfaces.
Linker:
* Remove Linker::makeCommentLink() without deprecation -- nothing calls
it and it is obviously an internal helper.
* Soft-deprecate Linker methods formatComment(), formatLinksInComment(),
commentBlock() and revComment().
Caller migration:
* CommentFormatter single: Linker, RollbackAction, ApiComparePages,
ApiParse
* CommentFormatter parametric batch: ImageHistoryPseudoPager
* CommentFormatter fluent batch: ApiQueryFilearchive
* RowCommentFormatter sequential: History feed, BlocklistPager,
ProtectedPagesPager, ApiQueryProtectedTitles
* RowCommentFormatter with index: ChangesFeed, ChangesList,
ApiQueryDeletedrevs, ApiQueryLogEvents, ApiQueryRecentChanges
* RevisionCommentBatch: HistoryPager, ContribsPager
Bug: T285917
Change-Id: Ia3fd50a4a13138ba5003d884962da24746d562d0
This change uses $contentLanguage->ucfirst( $name ) to get the
canonical username like this is done in UserNameUtils::getCanonical().
This makes the first character case-insensitive. The toUpperCase() in
JavaScript is not needed anymore.
toUpperCase() in JavaScript and $contentLanguage->ucfirst() in PHP
differ on some characters:
* JavaScript: "ß".toUpperCase() // "SS"
* PHP: $contentLanguage->ucfirst( "ß" ) // "ß"
Bug: T291339
Change-Id: Id9afb2dd0212e4b871bb6a7a9d8762e1bcb81d6a