Author: mike.lifeguard+bugs
Description:
The current search function can search only for target and initiator, and cannot accept wildcards. Please allow wildcard or regex searching, and allow searching by wiki (once bug 13789 is done), and allow searching in the reason.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T139810 RFC: Overhaul the CheckUser extension | |||
| Open | None | T132892 CheckUser UI revamp | |||
| Resolved | Feature | Dreamy_Jazz | T16699 More versatile searching in CheckUser log | ||
| Declined | None | T15789 Restore the global CheckUser log | |||
| Resolved | Feature | Dreamy_Jazz | T309924 Add check links for both the target and performer in Special:CheckUserLog | ||
| Resolved | Feature | Dreamy_Jazz | T309925 Implement User:Amalthea/culoghelper.js into the CheckUser extension |
Actually, at least two other indexes would be needed too, since the current ones are on user ID's. This is starting to become a bit much...
Bah, and the comment index needs to be fulltext, which needs a separate non-innodb table.
Closing this as it would be *too* much of a pain for not enough benefit.
mike.lifeguard+bugs wrote:
Are we sure we can't get a half-decent search on the target at least? That'd be really useful for cases where one doesn't remember the exact name.
Even if we don't get all the searchability we want, we could do with a bit more :)
In order to find recent concerns about a long time sock puppeter, the search form is useless at the moment. This is necessary when doing audit work, and also considering ban appeals.
The only solution right now is to:
a) ask all checkusers if they have done recent related checks, or
b) load a log of the last year and search.
Can you be more specific about the proposed use cases we don't cover currently?
How should a "ban appeal search" look like? How do "audit work" searches look like?
This might help to provide a faster and easier solution to most frequent problems.
Change 800827 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CheckUser@master] Allow CheckUserLog searching by cul_reason with wildcards
Change 800827 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Allow searching CheckUserLog by check reason with wildcards
(not sure if I'm right in adding Schema-change-in-production to this, but rather safe than sorry..)
You need to create a separate ticket. See https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change
Change 803260 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CheckUser@master] Add a temporary config var for writing reasons to the comment table
Change 802951 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[mediawiki/extensions/CheckUser@master] Revert "Allow searching CheckUserLog by check reason with wildcards"
Change 802951 abandoned by Urbanecm:
[mediawiki/extensions/CheckUser@master] Revert "Allow searching CheckUserLog by check reason with wildcards"
Reason:
my mistake, shouldn't break things immediately (it checks for field existence).
Change 802951 restored by Urbanecm:
[mediawiki/extensions/CheckUser@master] Revert "Allow searching CheckUserLog by check reason with wildcards"
Change 803260 abandoned by Dreamy Jazz:
[mediawiki/extensions/CheckUser@master] Add a temporary config var for writing reasons to the comment table
Reason:
Entire patch was reverted for this train so no need for this right now.
Change 802951 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Revert "Allow searching CheckUserLog by check reason with wildcards"
Change 803298 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CheckUser@master] Add cul_reason_id and cul_reason_plaintext_id into cu_log
The above patch adds the two columns that the since reverted patch depends on to work.
If you want to make this happen I won't block you but the better way to generally do this is to actually make it use the core's logging system. CU is fully reinventing the wheel here because back then core didn't have private logging system but now it does and OS uses that. Migrating data and etc. will be fun and I'm not sure it'll allow this feature but it would fix a lot of issues.
There are a number of issues that I could see relying on cores logging system that would probably need to be overcome:
I don't feel I have the knowledge of MediaWiki to do this merge and so unless there is someone who will work on this then it will I guess then just delay any changes to the CU extension that require a change to the cu_log table?
An assumption I've made about the DB is that it can recognise that the hash is going to be the same for all rows with the same comment. In theory, if the DB does not do this already, the searching could be simplified such that the hash of the search reason could be calculated and then instead of searching for matches in the text the DB could instead search for matches of the hash as it has an index in the comment table. This wouldn't work for wildcard searching but if a JOIN with a equals to the text value is an expensive operation this could speed things up.
Change 803298 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Add cul_reason_id and cul_reason_plaintext_id into cu_log
Change 879883 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CheckUser@master] Add reason search in CU log and move plaintext gen. code to a service
Change 879883 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Add reason search in CU log and move plaintext gen. code to a service
I'm going to close this as resolved and split any remaining tasks into other tasks as this has become a bit of a catch all for improvements to the CheckUserLog.
Searching by reason has been implemented for direct matches. Wildcard search will take a fair bit more work that may require another table.
With respect to the other things: