The ApiQueryCheckUser class provides an API to lookup data from the cu_changes table. To prepare for T341827, the fields being used in the SELECT queries need to be aliased to remove the cuc_ prefix. This allows the code to read rows from a IResultWrapper without having to know which table the row is from.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Alias the select fields to remove cuc_ in ApiQueryCheckUser | mediawiki/extensions/CheckUser | master | +42 -30 |
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Resolved | Dreamy_Jazz | T341827 Add read new support to the CheckUser API | ||
| Resolved | Dreamy_Jazz | T360961 Create ApiQueryCheckUserAbstractResponse | ||
| Resolved | Dreamy_Jazz | T360072 Alias select fields in ApiQueryCheckUser | ||
| Resolved | Dreamy_Jazz | T360106 Improve test coverage on ApiQueryCheckUser | ||
| · · · |
Change 1011006 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CheckUser@master] Alias the select fields to remove cuc_ in ApiQueryCheckUser
Change 1011006 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Alias the select fields to remove cuc_ in ApiQueryCheckUser
For this task I would suggest testing that no changes are observed in the functionality and in what data is returned by the API. This is because this change should have made no changes to the returned data or API interface.
Thanks. I have made various requests to the ApiQueryCheckUser API before and after this change.
The only difference I have seen appears to be because we no longer include cuc_xff in the userips query. This can change the order in which results are returned, affecting which rows are within the query's LIMIT. Where a user has multiple edits from different IPs/XFFs with the same timestamp, things like editcount and start can differ before and after this change.
Test environment: local docker CheckUser 2.5 (3c38f9a) 07:19, 26 March 2024.