This is an archive of past discussions with User:GeneralNotability. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
RoySmith, you would mark Php2000 as a CU-confirmed master and the rest as CU-confirmed (or whatever) socks in the main column, and then would mark Filologo2 as suspected (or proven, depending on how sure you are) alternate master. This would then add the altmaster field to every tagged sock. GeneralNotability (talk) 15:09, 26 November 2020 (UTC)
GeneralNotability, I think I followed the instructions above, but didn't get what I wanted. I don't understand how "mark Filologo2 as suspected ... alternate master" differs from "add the altmaster field to every tagged sock". Could you do a screen shot illustrating what you mean? -- RoySmith(talk)16:01, 26 November 2020 (UTC)
GeneralNotability, Um, no, that doesn't seem right. Php is the confirmed master, and Flologo2 is the suspected. So I tried the attached and that didn't do the right thing either. I think at this point, while I appreciate your help, the effort of getting this right exceeds the value, so I'm just going to leave it as it is. -- RoySmith(talk)21:37, 26 November 2020 (UTC)
Hmmm, that came out a bit testy, which is not at all what I intended. I really do appreciate the effort you've put into this, both in developing this script, and in answering my questions (always cheerfully). But, there's more socks to be caught and not enough time to catch them all. -- RoySmith(talk)22:18, 26 November 2020 (UTC)
Bug reports
Moving to GitHub for better tracking, please file new issues here. If you don't have a GitHub account, open a new section rather than adding a bug here.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Sock tagging
Firstly, thanks heaps for working on this GeneralNotability! Regarding sock tagging, when I tried to correct the tags on sock user pages, the script added the same account as both master and altmaster. I had the altmaster tag set to none on the SPI page when I used the script. See the history of Roxy Benelux for an example. Callanecc (talk • contribs • logs) 01:13, 11 July 2020 (UTC)
Callanecc, did it prompt you for altmaster on the SPI page when you hit the "done" button? If so, I've seen this bug a few times but haven't quite figured out where it's coming from. I'll spend some time on it tomorrow and see if I can get a reproducible test case. Workaround for now - if it does prompt you for altmaster and you didn't actually want to tag an alternate master, just blank the prompt and hit enter, that should make it not fill out the altmaster fields. GeneralNotability (talk) 01:26, 11 July 2020 (UTC)
It did prompt for the master (I don't remember it saying altmaster but it may have) and it prefilled MED0600. I'll have a look if I do a similar thing again. Callanecc (talk • contribs • logs) 01:35, 11 July 2020 (UTC)
Callanecc, aha! that cracked the case. If the "do not make blocks" button was checked, it took a different route through the code that I hadn't noticed and that route didn't handle the altmaster correctly. Should be fixed now. GeneralNotability (talk) 12:53, 12 July 2020 (UTC)
@GeneralNotability: For some reason none of your pings to me worked either...weird. oh and in edit summaries templates don't work, you have to wikilink to userpage. The one-click menu is the one that Both ways just skip to "done", but the longer way actually says it saved the case page....without actually making a single edit. --TheSandDoctorTalk16:24, 11 July 2020 (UTC)
Thanks for the great feature around renaming SPI pages. When the target SPI page already exists, the script gives the "articleexists" error, but still follows through with the rest of the actions. Ideally the revisions in the page should be history merged (delete target page, move the page leaving (or not) a redirect, restore deleted revisions in the target page). It would also need to ensure that previously deleted revisions at the target page are kept deleted. And then also that all the cases on the pages are listed on the target page after the history merge. Dreamy Jazztalk to me | my contributions13:10, 19 July 2020 (UTC)
Dreamy Jazz, I haven't tried to add support for histmerge yet, that button currently will only work for an easy move (target page doesn't exist). I'll add a check to stop editing if the target already exists and put histmerge on the requested features list. GeneralNotability (talk) 13:59, 19 July 2020 (UTC)
Dreamy Jazz, I got bored - it will now do the histmerge if you're an admin (with a warning prompt) and bail out if not. Next time you have a case merge, feel free to give it a try (and keep a close eye on it - it worked in testing, but I'm sure something could go wrong) GeneralNotability (talk) 00:30, 20 July 2020 (UTC)
Settings are not set properly
Hi. Thanks for making this! I, being a non-clerk, would like to disable the clerk options. Following the instructions in the documentation, I've set User:Mdaniels5757/spihelper-options.js to have clerk:false. However, it is never reflected in spiHelper_isClerk. See the below for why:
Consider what would happen if lines 39-40 were changed to
// Load local settings if presentconsole.log('a');spiHelper_loadSettings();console.log('c');
and the following were added in spiHelper_loadSettings:
// This is all old....spiHelper_settings[k]=v;});// The following is the only new line.console.log('b')
My console should have a, b, and c in that order (it has to be that way, for spiHelper_isClerk to be properly set); and spiHelper_settings.clerk and spiHelper_isClerk should both be false. However, my console prints a, c, b; spiHelper_settings.clerk is false (correct), and spiHelper_isClerk is true (incorrect). I'm guessing that's because constspiHelper_isClerk is set before the settings get the chance to load. Best, —Mdaniels5757 (talk • contribs) 21:55, 12 August 2020 (UTC)
The checkuser / checkIP template added when a case is moved should not have gaps which visually separate the lists. For example in this diff the checkuser template was placed above two line breaks leaving a gap in the list. This is likely because two spaces were under the "Suspected sockpuppets" section in the pre-move case wikicode and the new checkuser template was simply appended to the top. Perhaps placing the template under any whitespace at the beginning of the section, or finding the first checkuser / checkIP template in that section and adding it above that would be better.
checkuser template is removed from cu results after case move
It seems like to avoid duplication in the suspected sockpuppet list after a case move any checkuser templates which have the new sockmaster for the case as the username are removed. This is desirable in the suspected sockpuppet list, but it has the (presumably) unintended side effect of removing the template in comments by checkusers giving the checkuser results. For example, in this diff where I moved the case to the oldest account, the checkuser template is removed from the checkuser results in the clerk/cus/patrolling admins section. Perhaps it might be worth only removing the relevant {{checkuser}} templates when they are below the "suspected sockpuppets" section header and they are before any non-list content? Dreamy Jazztalk to me | my contributions21:03, 27 August 2020 (UTC)
Dreamy Jazz, oops. Yup, I see how that could happen - I forgot to account for the fact that CUs will sometimes add new entries in a bulleted list format. Will work on a fix for that soon. GeneralNotability (talk) 21:06, 27 August 2020 (UTC)
This edit had no edit summary (there is the appended (using spihelper.js), but nothing else). Although the change had no visual effect (no first parameter and open mean the same thing for the {{SPI case status}} template), it is probably best to still include some sort of edit summary. Perhaps small edits without a defined edit summary could have the edit summary common fixes or something like that. This is not an important or urgent, so feel free to ignore. Dreamy Jazztalk to me | my contributions12:56, 14 September 2020 (UTC)
Non-archived cases removed on the target page when history merging a case
This edit history merged the case over, but then in the process it removes any cases left unarchived on the page. The script should account for the removal when history merging and restore any unarchived case on the target page. The edit the script should make is this one I made manually. The way I think this could be done is by keeping a note of the last revision id on the target page (or the content in said revision) before the merge and then adding case(s) in this revision back into the page (above the now merged cases, so like the edit I made). Dreamy Jazztalk to me | my contributions11:44, 19 September 2020 (UTC)
Wasn't as complicated as I thought, but there still could be some fiddly bits (mostly de-duplicating the SPI headers). Queued in dev but I'll want to do some testing before I call it ready. GeneralNotability (talk) 16:45, 25 September 2020 (UTC)
Dreamy Jazz, yeah, I know about that one. I think I have a fix for that queued in dev already (I have a regex in there to strip the header but I think the current regex is wrong), I just haven't had a case merge lately to test with. I'll try to move dev -> deployment this weekend. GeneralNotability (talk) 23:40, 2 October 2020 (UTC)
Watchlisting settings not working as expected for local overrides
Reported by AmandaNP - she has "watchlist pages I create" set to true globally but a local exception for enwiki sets it to false, but she's still getting pages watchlisted. I blame the mediawiki API, since the option I'm using (theoretically) will have the API decide based on the user's preferences. A workaround while I investigate this: create Special:MyPage/spihelper-options.js with the following content:
Found the issue - I was expecting the block API to take the same string input as the edit API for the "watchlist" setting, but no, it's a boolean. Fix queued in dev. GeneralNotability (talk) 15:05, 15 October 2020 (UTC)
A block talk page template is added when a block fails
In this case the block failed because I hadn't enabled override blocks, but a block talk page template was placed for the failed block (I had asked the tool to place a block notice for the sockpuppet and master). The tool probably shouldn't place the notice if the block failed for any reason (not just because they are already blocked) and also notify the user of the tool that the talk page block notice wasn't placed. Dreamy Jazztalk to me | my contributions12:03, 30 September 2020 (UTC)
Rangeblock template was not used in the block summary when an IP range was blocked
In this case, I filed a pro forma SPI report. I then used the tool to block. I added "/24" to the username input box for the IP address so that that row in the block table was now for a range block. I then blocked with normal settings. Instead of the usual summary for a range block (i.e. {{rangeblock| ...}}), the range block template was not included in the block summary (see block log for the range). This is inconsistent to the usual behavior and I think it is because the script determines the block summary when the the block menu is opened. Perhaps its best that the block summary is determined when the done button is pressed, so that it ensures the correct block summary is used when blocking. This isn't a major issue and fixing it would be only for the sake of consistency, as the rangeblock template being present in the block summary is not strictly necessary. Dreamy Jazztalk to me | my contributions18:56, 1 October 2020 (UTC)
Dreamy Jazz, weird, it should be doing exactly what you say it should be (generating summary at block time), and clearly the updated data from the field is being passed into the function since it did a rangeblock...I'll keep an eye out the next time I do a rangeblock and see what's going wrong. GeneralNotability (talk) 20:52, 1 October 2020 (UTC)
GeneralNotability, I've done a big of debugging (see my copy at User:Dreamy Jazz/spihelper.js). When I performed the same actions, mw.util.isIPAddress(targetUser, true) returned false. This means that the condition } else if (isIP) { evaluates to false and so the code to add the range block template if there is a slash never runs. The value of targetUser is 103.29.98.116/24 according to the console
When I add {{checkip|1=103.29.98.116/24}} to the page and then attempt to block that (so the value is the same as before, but I didn't modify it in the script to be a range block) mw.util.isIPAddress(targetUser, true) returns true.
I thought that somehow the value in targetUser has some issue. I printed out all the character codes in the string. What was strange was that when I added the "/24" the character code "8206" was the first character. This, it turns out, is the left to right Unicode decimal character code. It was the only character not present when I didn't add anything to the username. I therefore have assumed that the function mw.util.isIPAddress doesn't like when there is a left to right marker as the string to check. For a workaround, removing this character should fix the problem. Dreamy Jazztalk to me | my contributions22:04, 1 October 2020 (UTC)
I have a regex fix. I thought it didn't work and spent ages trying to debug why firefox wasn't running the code, but it was a combination of forgetting "var" and my inability to click a checkbox. From my testing it works in google chrome and firefox. It seems like when the textbox has stuff added the brower helpfully adds the left to right character code at the start of the string. This causes with the regex that mw.util.isIP4Address uses to return false because there is a character which is not a number at the start of the string, so the string cannot then be an IP address. mw.util.isIP4Address is used by mw.util.isIPAddress to implement the check.
The fix is basically to remove any occurrences of this character only when checking if the username is an IP address. The replace is only there to keep the regex in mw.util.isIPAddress happy. Essentially the code would be const isIP = mw.util.isIPAddress(targetUser.replace(/\u200E/, ""), true);Dreamy Jazztalk to me | my contributions22:49, 1 October 2020 (UTC)
Dreamy Jazz, thanks, that is very helpful. I'll borrow that, though I'm going to poke around the mediawiki JS libs to see if there's some kind of built-in string normalizer I could be using. GeneralNotability (talk) 23:12, 1 October 2020 (UTC)
checkuser templates not being parsed since changes to SPI report
These two changes to the SPI report preload template cause |master name={{#titleparts:{{SUBPAGENAME}}}} to be added to all checkuser / checkip templates when filing. This seems to mess with the detection code in spihelper and results in these users not being listed in the block/tag list. Removing the extra parameter fixes the problem for that case (so the checkuser / checkip templates are found and the users are listed). I forgot to file a report for this before. I'm guessing you already know about this, but just incase you don't I've filed this. Dreamy Jazztalk to me | my contributions17:51, 5 October 2020 (UTC)
I can't see why this parameter is needed, as surely this could be handled by the template itself (i.e. the default should just be defined as this wikicode), but it breaks the tool, so I thought it best to post here. Dreamy Jazztalk to me | my contributions17:53, 5 October 2020 (UTC)
Dreamy Jazz, yuck...clearly jackmcbarn isn't using spihelper, because I've never clicked the "tag" button in my life. I'll see if I can roll a fix for this. I agree the default would probably be better in the template, but the template would need some smarts (since it should only try to default-fill like that if it were on an SPI case page) GeneralNotability (talk) 18:16, 5 October 2020 (UTC)
Well, guess now is as good a time as any to deploy dev to production. Parsing should be fixed in 2.2.11, let me know if you're still seeing issues (there are two places the template is parsed: generating the list of suspected socks and removing the new master during a case move). I am steadfastly refusing to actually add this template when spihelper adds {{checkuser}} (on grounds of "if you're using spihelper you're not using that link anyway"). GeneralNotability (talk) 18:30, 5 October 2020 (UTC)
Dreamy Jazz, nope, it's not coded to archive, so not sure what happened there, the only thing I can think of is that something went wrong when it was getting the existing page text. I'll keep an eye out for this happening again. GeneralNotability (talk) 19:22, 9 October 2020 (UTC)
extra horizontal lines added when restoring previous cases
"Failed to block ..." still shown when override blocks is enabled
When blocking at Wikipedia:Sockpuppet investigations/DavidBiga, I first blocked without overwrite blocks ticked, so the script didn't block Nmgwikiteam. I then re-ran the script to block Nmgwikiteam with overwrite blocks enabled. It did block, but I still got the message in red "Failed to block Nmgwikiteam: alreadyblocked". It would be best if this message is not shown when the block is actually made. Dreamy Jazztalk to me | my contributions18:07, 23 October 2020 (UTC)
Dreamy Jazz, I've seen that issue before, but have not conclusively identified the cause - I think that the API is throwing "alreadyblocked" when the block has the same blocker and block params as the current block, but I have no idea why that would happen. It does not happen if overriding someone else's block. GeneralNotability (talk) 18:22, 23 October 2020 (UTC)
Warning about not placing talk page block notice when block was successful, and also when the block was not successful but a placing talk page block notice was not enabled
When blocking at Wikipedia:Sockpuppet investigations/DavidBiga, both when the block was not executed and when it was, the message saying that a talk page notice was not placed was shown. I hadn't enabled "Add talk page notice when blocking socks", so it seems this message is shown regardless of whether this tick box is clicked. The message should ideally only be shown when the checkbox is ticked (both for blocking the sockmaster / for blocking sockpuppets), and when the block actually failed. Dreamy Jazztalk to me | my contributions18:12, 23 October 2020 (UTC)
When history merging cases into a page with the same letters but different capitalisation (excluding differences in capitalisation the of first letter), the clerk note is added without the checkuser template
When history merging Wikipedia:Sockpuppet investigations/Bessieloo into Wikipedia:Sockpuppet investigations/BessieLoo the the code does not add the checkuser template, but the clerk note is still added. The checkuser template with the previous case name should be added unless the the only change in capitalisation is at the start of the username. In this case the letter l was differently capitalised, but this was not at the start of the username, so in theory both usernames could be attached to accounts. Furthermore, it would be good to check that the clerk note isn't added when the checkuser template shouldn't be added (i.e. when the only difference is the capitalisation at the start). See this diff with the issue. Dreamy Jazztalk to me | my contributions18:49, 30 October 2020 (UTC)
RoySmith, well, the problem there is that it added a second "all comments above this line" entry and then anchored your comment on that. I'm trying to figure out how it managed to add that, though... GeneralNotability (talk) 14:01, 2 November 2020 (UTC)
GeneralNotability, I think what I did on that one was reblocked some already-blocked users and forgot (as I usually do) to check "Override any existing blocks". So, maybe it has something to do with not catching the error properly? -- RoySmith(talk)15:15, 2 November 2020 (UTC)
Edit conflict
Unfortunately, I wasn't alert enough to grab the exact error message, but when I closed Wikipedia:Sockpuppet investigations/Pcsastrys5, I saw it say something like "Edit failed on Wikipedia:Sockpuppet investigations/Pcsastrys5: edit conflict". It correctly executed the block and the tag, but sure enough, didn't update the SPI page itself. There's no way I actually edit conflicted for real. The previous edit was at 2020-11-07T02:58:04 and my block was applied at 2020-11-07T03:04:40 (6 minutes later). Even if there actually was an edit conflict, you should at least preserve the failed text and make it available for reuse. -- RoySmith(talk)03:13, 7 November 2020 (UTC)
RoySmith, hmm...what it's doing there is grabbing the page revision at load time and sending that to the edit API (which decides whether there's an edit conflict). I'd need to see if there's a practical way to check for an edit conflict before closing the action view, not sure how practical that is. GeneralNotability (talk) 14:30, 7 November 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
