This page is an archive of past discussions. 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.
after, or both, which causes grief for Fastily's bot, but a tweak is needed. Ta. Cabayi (talk) 14:49, 16 November 2020 (UTC)
Cabayi, ahh, that's what's making those cases pop up as malformed. I'll just add both. Fix queued in dev. GeneralNotability (talk) 15:34, 16 November 2020 (UTC)
Alt masters?
Latest comment: 3 years ago6 comments2 people in discussion
In Wikipedia:Sockpuppet investigations/Filologo2, I want to tag the socks as confirmed to Php2000, with a suspected alt-master of Fiologo2. It's unclear how to do that. It obviously involves the Alt Master column some how, but the details elude me. -- RoySmith(talk) 15:03, 26 November 2020 (UTC)
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)
Sure, it should look like this screenshot. GeneralNotability (talk) 20:06, 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
Latest comment: 3 years ago69 comments7 people in discussion
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)
@GeneralNotability: It occurred again at Wikipedia:Sockpuppet investigations/Romello Brooks. When I had the Do not make any blocks (this overrides the individual "Blk" boxes below) option selected, a popup didn't appear, and the undefined altmaster bug occurred. When I tried again, without that option ticked, but instead manually unticked all of the Blk? options it worked correctly. Callanecc (talk • contribs • logs) 03:37, 12 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: Archiving appears to have broken now. It just skips to 'Done (Reload page)" without actually archiving. --TheSandDoctorTalk 07:02, 11 July 2020 (UTC)
TheSandDoctor, moved here from the clerk noticeboard. Is this one-click archive or the normal SPI interface archive, and what page did this happen on? GeneralNotability (talk) 14:17, 11 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. --TheSandDoctorTalk 16:24, 11 July 2020 (UTC)
TheSandDoctor, should be fixed now - there was an issue with how it handled calculating the post-move page size when there was no archive. GeneralNotability (talk) 18:20, 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 contributions 13: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)
Mdaniels5757, ah, yes, javascript not executing things in order. Wonderful. I'll put it on the to-do list, should be pretty straightforward. GeneralNotability (talk) 00:41, 13 August 2020 (UTC)
Whitespace issues after moving a case
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.
Dreamy Jazz, yup, that's a good thought. I've got a possible fix in my IDE copy of the code, I'll put it into -dev this weekend and see if it works. GeneralNotability (talk) 16:18, 14 August 2020 (UTC)
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 contributions 21: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)
Dreamy Jazz, released an update an hour or so ago which should fix this issue. GeneralNotability (talk) 17:16, 29 August 2020 (UTC)
Dreamy Jazz, good spot, queued in dev (probably will copy dev -> production today or tomorrow). GeneralNotability (talk) 14:21, 14 September 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 contributions 12: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 contributions 11:44, 19 September 2020 (UTC)
Dreamy Jazz, yeah, I've seen that one before...I'll look into it, but I think it'll be a complicated fix. GeneralNotability (talk) 16:31, 23 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)
GeneralNotability, thanks for the update. No worries if it takes some time, it's easy to highlight and delete content anyway in the meanwhile. Thanks for dealing with all my bug reports. Dreamy Jazztalk to me | my contributions 23:42, 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 contributions 12: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 contributions 18: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 contributions 22: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 contributions 22:49, 1 October 2020 (UTC)
Hopefully that is helpful. Was useful for me at least to practice my javascript and debugging. Dreamy Jazztalk to me | my contributions 22:56, 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 contributions 17: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 contributions 17: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)
Sure. I will do. I agree that its probably best for the tool not to add it for the reasons you specify. I think I've never used it either. Dreamy Jazztalk to me | my contributions 18:42, 5 October 2020 (UTC)
spihelper_log blanking itself
This edit by the tool blanks the spihelper_log and then adds the current log entry. Is this in the intended behavior? I ask because I can't see anything in code in the function for logging which explicitly removes logs. Dreamy Jazztalk to me | my contributions 18:56, 9 October 2020 (UTC)
I would prefer that once the page becomes too large I can move the entire page (and revisions) to a subpage to archive them, then start fresh. Dreamy Jazztalk to me | my contributions 19:04, 9 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
This diff add a horizontal line before moving when there are no cases on the page and when restoring cases already on the page the two horizontal lines then exist at the bottom of the page. This was repeated to make three in this diff and then this diff. My suggestion is to not add the horizontal line in the "saving page" edit when there are no cases on the main page (i.e. not the archive). Dreamy Jazztalk to me | my contributions 11:05, 21 October 2020 (UTC)
Okay, good idea - I'll only check if the horizontal rule is needed (and add if necessary) when making a comment. Will queue in dev. GeneralNotability (talk) 18:18, 23 October 2020 (UTC)
"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 contributions 18: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)
I can't see why I blocked twice. My spihelper_log only shows that I ran the tool once at 19:04. That's a bit strange. Dreamy Jazztalk to me | my contributions 18:32, 23 October 2020 (UTC)
Dreamy Jazz, I can't be sure, but I think I've seen this too. -- RoySmith(talk) 18:43, 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 contributions 18: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 contributions 18:49, 30 October 2020 (UTC)
Comments below the line
Could you take a look at this. spihelper put my notes below the "all comment go above this line" line. -- RoySmith(talk) 03:06, 2 November 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)
Ahhh, it's because the entry above only had three dashes...that would do it. GeneralNotability (talk) 14:23, 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.
