| Urbanecm | |
| Apr 6 2020, 10:21 PM |
| F31787968: image.png | |
| Apr 30 2020, 8:56 AM |
Checkusers might want to make the block the most strict one (no email, no talk edits) and also tag them at their userpage. However, checkuser skips all currently blocked users.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Reblock and tag blocked users in Special:Checkuser | mediawiki/extensions/CheckUser | master | +42 -67 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Urbanecm | T249562 Checkuser should allow reblocking users and tag pages even if users are already blocked | |||
| Resolved | Tchanders | T252892 Fix flag set on block by SpecialBlock::processForm if $wgBlockAllowsUTEdit is false |
Change 586462 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/CheckUser@master] Reblock and tag blocked users in Special:Checkuser
We might want to hear from a few more users about this? Presumably the check users would have to be a bit more careful about using this form if we make this change. E.g. they may need to check whether a user is suppressed, or they might accidentally unsuppress them. Similarly, if an IP is already blocked for longer than a week, they may not want to shorten the block.
On the other hand, we display "blocked" notice (through sometimes it's broken, cf https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/479457), so they should already know, IMO.
I don't mind asking them through. Should I email the list?
I personally would support this feature. In addition to the "blocked" notice provided by CheckUser itself (which is usually accurate), I think most CUs have a javascript that indicates users that are blocked with a strikethrough, and indef blocked users with italics and strikethrough. So, we know if they're blocked. Often, I do want to re-block them, either to use the {{checkuserblock-account}} template, to change the block from temporary to indefinite, and occasionally to revoke talk page access for a sockpuppeteer which routinely abuses it.
If there's disagreement on this, then a checkbox to "Override any existing blocks" would be nice.
Agreed. If we’re clicking the block button that means we want it blocked with the reason we input. If they’re already blocked it should reblock.
I think this should be optional; meaning that you should have control as to whether the block should be reinstated and the tag updated or not.
Also, it may be worthwhile reminding the CU that if the block is replaced with an identical block (e.g. if you are trying to indef block a user that is already indef blocked), no action will be taken (e.g. no new block log is created). And we should make sure tagging user page works regardless.
It would already be optional: you will see if the user is blocked or not. If you check the blocking checkbox, why should the software mean you didn't mean to alter the block?
Also, it may be worthwhile reminding the CU that if the block is replaced with an identical block (e.g. if you are trying to indef block a user that is already indef blocked), no action will be taken (e.g. no new block log is created). And we should make sure tagging user page works regardless.
Shouldn't that change the reason at the very least?
Right. I didn't think about it from that angle.
Also, it may be worthwhile reminding the CU that if the block is replaced with an identical block (e.g. if you are trying to indef block a user that is already indef blocked), no action will be taken (e.g. no new block log is created). And we should make sure tagging user page works regardless.
Shouldn't that change the reason at the very least?
Interesting. I thought it wouldn't. But I just tested it and it actually does. Ignore my comment altogether then.
@Urbanecm Did you email the list? I don't know nearly enough about the checkuser blocks to know if this is a good idea or not. I think it would be valuable to run it by other checkusers to see if they agree.
I wonder if this javascript is present on all projects that have checkusers and whether they all know about it and understand what the bold, italics, strikethrough means.
If there's disagreement on this, then a checkbox to "Override any existing blocks" would be nice.
This seems like a good idea to me regardless. It makes it more explicit that once they submit the block, all existing blocks would be overridden.
As @TonyBallioni said, as a CU I agree with the proposal of overriding blocks when we chose to block through the CheckUser tool.
As a CU, being able to override previous blocks looks good to me. However I'd prefer if a specific checkbox existed in the blocking options for that so overriding blocks is not done by default. Thanks.
@Urbanecm Can you add a screenshot here of the end result? That would be helpful. Thanks.
@Niharika Indeed, we may want to update https://en.wikipedia.org/wiki/File:Special-checkuser-get-users_en.png with a new version once this gets +2'ed.
@Urbanecm Seems like there's consent here and I feel better about this with the explicit override checkbox. Anything else you heard on the mailing list?
Great. Thumbs up from me on this ticket. @Urbanecm if you need help reviewing the code, let me know and I can request someone on my team to look into it.
Thanks :). Well, I think only code review is needed now. Looking forward to the reviews :).
Change 586462 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Reblock and tag blocked users in Special:Checkuser
Submitting the form with new checkbox unchecked:
With the box checked:
I compared before and after this change to check that the block parameters have stayed the same.
Testing on a mixture of local vagrant and testwiki (after the train).