User talk:SQL/AIVAnalysis Source: en.wikipedia.org/wiki/User_talk:SQL/AIVAnalysis

Bug Squashing

Bot does not follow renames. SQL ^{Query me!} 22:37, 5 December 2017 (UTC)[reply]
Fixed - And now it does! SQL ^{Query me!} 03:02, 6 December 2017 (UTC)[reply]
This has returned with the webtool. Queries against logging_userindex are relatively expensive timewise. I may need to write a caching function so at least we only have to experience them once. SQL ^{Query me!} 23:56, 23 December 2017 (UTC)[reply]

Users with oversighted block log entries show up as not blocked. There is no way that I am aware of to get around this. SQL ^{Query me!} 22:27, 5 December 2017 (UTC)[reply]
I have an ugly / hackish workaround for this. Screen-scraping "https://en.wikipedia.org/w/index.php?title=Special:Contributions/" . $username . "&offset=&&limit=1" for "This account is currently blocked" seems to work. These blocks do not show up in API:Blocks, Special:IPBlocklist, nor the Block log - so this was a truly last resort. Running a test case (72's had a few of these) now to confirm. SQL ^{Query me!} 01:23, 6 December 2017 (UTC)[reply]
Fixed - guess it wasn't a can'tfix after all! SQL ^{Query me!} 01:54, 6 December 2017 (UTC)[reply]
This issue has returned with the webtool. I probably need to check the ipblocks table in addition to logging. SQL ^{Query me!} 23:56, 23 December 2017 (UTC)[reply]

Bot should check to see if the IP is under a rangeblock. SQL ^{Query me!} 22:37, 5 December 2017 (UTC)[reply]
Anyone have a good way to check for this via the API or maybe a screen scrape? SQL ^{Query me!} 01:30, 6 December 2017 (UTC)[reply]

This report contained a typo; it was corrected a moment later by me, and the account was blocked a few minutes later. It's understandable why your tool didn't pick it up, but maybe a check against case sensitivity if the account tagged at AIV isn't registered?
This one shows as a never been blocked, but was again a typo. The actual account name was corrected by another editor. This time, I inadvertently left the "e" on the end of "username" in when I selected "usernam" (minus the trailing 'e') for replacing the username. No idea how to account for a typo like that :/ Leave it to a human to really mess things up.
This one is a special case; I made this request when that account was already blocked; I was asking for a change in the block settings. The bot immediately removed the request, so I then made this request with an intentionally wrong username (adding 'NNN' to the end) so the bot wouldn't immediately remove it. The change in block settings I requested was done [1].

Occasional "Undefined Index: Compare" on line 53. Need to add a trap to that and see why. SQL ^{Query me!} 01:26, 6 December 2017 (UTC)[reply]
Fixed with the webtool. SQL ^{Query me!} 23:56, 23 December 2017 (UTC)[reply]

This one was just a typo done by accidentally copy/pasting {{Vandal|username}} per the instructions and not changing "username". Maybe it could ignore "username" as an account name as that is obviously in error. This request immediately preceded the above request, and was done in error. The same text for a request appeared in the next AIV report I made, albeit with the proper username put in.
Fixed Bot now discards the username "username". SQL ^{Query me!} 21:44, 5 December 2017 (UTC)[reply]

This report resulted in a block of the account. I don't know why your tool didn't pick it up.
This report resulted in this block. Again, I don't know why your tool didn't pick it up. There was a global lock too; maybe that threw it?
This report resulted in block. I don't know why your tool didn't find it.
The template was used with the 1= parameter - I did not think to check for this. SQL ^{Query me!} 21:54, 5 December 2017 (UTC)[reply]

Fixed SQL ^{Query me!} 21:59, 5 December 2017 (UTC)[reply]

At the moment, the script does not check to see WHEN the block happened, just IF it did. At some point, I will probably refactor it to see if the user was blocked within 24 hours of the AIV report. SQL ^{Query me!} 22:40, 5 December 2017 (UTC)[reply]
Now that we've moved to a web-based tool, this seems to be Fixed SQL ^{Query me!} 23:56, 23 December 2017 (UTC)[reply]

If a user re-adds a report from another user (accidentally removed / etc), it does count against that user. For the moment this can't be fixed because doing so would not count edits made by renamed users. SQL ^{Query me!} 22:36, 5 December 2017 (UTC)[reply]

Use 0MQ to spawn 5-10 worker clients to speed up the queries, respecting maxlag=3 or possibly lower. Currently, maxlag is set to 4. SQL ^{Query me!} 01:24, 6 December 2017 (UTC)[reply]
Doing... 90 lines of code in so far. SQL ^{Query me!} 03:49, 7 December 2017 (UTC)[reply]
Not done - no longer needed. SQL ^{Query me!} 23:56, 23 December 2017 (UTC)[reply]