User talk:GeneralNotability/spihelper/Archives/2021/January

Feature request

These are more like minor inconveniences, so if these changes aren't possible, it's not such a big deal. Today I wanted to close two case sections at once, but that doesn't appear to be possible (see [1]). If we could close or change case status on all sections at once, that would be a nice improvement. Also, it's very helpful to be able to archive individual case sections, but when there's multiple closed sections I want to archive at once, it would be nice if that could be done in one edit as opposed to multiple ([2]), like with the the old SPI script. Just so the page histories doesn't have to be clogged up with so many archive edits. Again, these are really minor complaints so I won't feel too bad if these changes can't be implemented. Sro23 (talk) 22:25, 30 December 2020 (UTC)

Sro23, as GN prefers issues / feature requests be now made on github, I've copied your request into https://github.com/GeneralNotability/spihelper/issues/15. I'm happy to copy comments over as wanted if you don't wish to use github. Dreamy Jazz ^{talk to me | my contributions} 22:31, 30 December 2020 (UTC)

I'd rather not open an account there so thanks. Sro23 (talk) 22:33, 30 December 2020 (UTC)

Sro23, I'll put it on the long-term nice-to-have list, but the way I reworked spihelper from the original (which didn't understand multiple-section cases) makes the multiple-section-change a pretty tough task. Basically, spihelper gets the internal section ID for each third-level heading, and then when you pick, say, "20 December 2020" it is passing that section ID to the MW API so it literally only retrieves text from and writes to that one section. Reworking that will be fairly messy. I might be able to consolidate the mass-archive into one edit, right now it's literally "for section in list_of_sections, if section is closed, archive(section)" (so it's the same function whether you're doing a single-section archive or mass archive, the latter just calls the function multiple times). GeneralNotability (talk) 00:20, 31 December 2020 (UTC)

Okay, it would be nice to have, but if it's going to be too much work then don't stress over it. Sro23 (talk) 00:38, 31 December 2020 (UTC)

Page protection

After I moved a case I saw MusikBot II (talk · contribs) remove the page protection icons. Could the case move process check the page protection of both source & target pages and apply the higher level after the hist-merge is done? Thanks, Cabayi (talk) 14:11, 9 January 2021 (UTC)

Cabayi, I've filed this on github for you as GN is preferring that issues are filed there. Dreamy Jazz ^{talk to me | my contributions} 14:42, 9 January 2021 (UTC)

Thanks Dreamy Jazz. -- Cabayi (talk) 14:48, 9 January 2021 (UTC)

TPA & Email

Could Sro23's request at Wikipedia talk:Sockpuppet investigations that TPA & Email aren't accidentally restored when reblocking be handled in the script by preloading existing block settings? Cabayi (talk) 16:14, 24 January 2021 (UTC)

Cabayi, yeah, but...there's a design decision to make here, since there are two scenarios: reblocking someone blocked without TPA/email, and blocking future socks, and I'd like to address both of those. Your/Sro23's request is fairly straightforward, I can prefill block settings based on the current block, but do we also want to use the sockmaster's block settings to prefill the socks' block settings? Or do we want an SPI param (like crosswiki=yes) to say "please revoke email/TPA/both" that spihelper reads? I can see arguments for either, and am interested to hear what you all have to say. Also ping Dreamy Jazz and Callanecc since you commented on the GitHub issue. GeneralNotability (talk) 19:18, 24 January 2021 (UTC)

I have noticed some cases mark at the top to remove TPA when blocking socks. Perhaps this could be made into a parameter and then the code reads that.

I would say that for cases where the sock might not be that user and revoking TPA is not necessary for socks, revoking TPA or email cause mistaken blocks to have to go through UTRS to appeal. In cases where the sock is ducky enough and the master is known to abuse TPA / email using blocked socks, then it makes sense to prefill the checkbox. However when the master had TPA / email revoked years ago, but does not abuse TPA or email with their socks, prefilling the checkboxes wouldn't be a good idea. My thoughts can be summarized that the checkbox should only be prefilled if it is necessary and has been marked as necessary.

My suggestion therefore is to have the prefill be based on existing block settings for the account, and have a parameter like cross-wiki to be able to prefill regardless of previous block settings. The parameter should display "Socks in this case should have TPA / email revoked because of previous abuse by sockpuppets" so it is clear it is set. Dreamy Jazz ^{talk to me | my contributions} 19:24, 24 January 2021 (UTC)

I was talking about reblocking socks already blocked, to adjust the block reason or what have you. I think were missing the bigger picture here. Generally it's common courtesy to not undo the original admin's block settings, or if you do, at least notify them. So it's kind of disrespectful to re-enable talk page and email settings after they were revoked, even though I get it's unintentional. A lot of these socks had their TP/email access revoked for posting really bad stuff (i.e. death threats) so there's that too. I'm not asking for any changes to be made to spihelper, I was just trying to get the message across that we should be responsible when using these blocking tools. And I wanted to keep it ambiguous, but the message was more intended for Checkusers to see rather than admin clerks since I've mainly seen CU doing this :) Sro23 (talk) 19:55, 24 January 2021 (UTC)

Sro23, yeah, I know what you were originally going for, I'm just taking this opportunity to rework other things related to prefilling the block options. GeneralNotability (talk) 00:07, 25 January 2021 (UTC)

Sro23, you may not be asking for any changes to be made to spihelper, I definitely am. If I'm using a tool to reblock a sock I'd really like it not to do it wrong. Having to double-check every setting on previous blocks of each sock is just the kind of timesink that spihelper saves us from.

So there's the question of reblocks where I think we're all on board with the existing block flags being honoured.

There's also the question of blocks on fresh socks where previous socks have had NTP & NEM set. Preselecting those flags muddies the waters - but does that matter? Alternatively the tool derives the most-restrictive set of blocks on all of the master's socks and suggests or applies those. Is that where we're at? Cabayi (talk) 13:18, 25 January 2021 (UTC)