Talk:CVNBot

Slashes in titles

I've confirmed in several channels (#cvn-wp-en^connect and #cvn-wp-nl^connect) that pages that contain a slash in their title (ie. "Wikipedia:Sandbox/Subpage" or "Sand/box" are NOT reported by CVNBot. I've been unable to find in the SWMTBot sourcecode why this is. Does anyone know more about this ? Krinkle 16:50, 23 May 2010 (UTC)

Sorry, no. Fairly serious bug... Who do we know that knows the bot source code well enough to track this down and fix it?  — mikelifeguard@meta:~$  15:40, 25 May 2010 (UTC)

Though I can't say for sure, I think it's got something to do with the following line 47 in RCReader.cs in SWMTBot 1.18

static Regex fullString = new Regex(@"^\x03" + @"14\[\[\x03" + @"07(?<title>.+?)\x03" + @"14\]\]\x03" + @"4 (?<flag>.*?)\x03" + @"10 \x03" + @"02(?<url>.*)\x03 \x03" + @"5\*\x03 \x03" + @"03(?<user>.*?)\x03 \x03" + @"5\*\x03 (?<szdiff>.*?) \x03" + @"10(?<comment>.*)\x03$");

A subpage edit in irc.wikimedia.org/#en.wikipedia looks like the following (without the colors, but check the irc.wikimedia.org-channel to see them)

rc:
[[User talk:82.74.192.60/Archive]] http://en.wikipedia.org/w/index.php?diff=364691190&oldid=364691134 * 82.74.192.60 * (+2256) test

I'm not a master in Regex'es so I didn't see anything wrong with it on first sight, but someone else might understand why it failed the "/". Krinkle 16:50, 28 May 2010 (UTC)

AFAICT, the (?<title>.+?) part is what captures the page title, and it is correct.  — mikelifeguard@meta:~$  22:10, 28 May 2010 (UTC)

right... I'll trace the result of that Regex and see if it goes wrong somewhere else. Note: Deletions of slash-containing-pagetitles do get reported by the bot. And knowing that with Log events the "page" in the irc.wikimedia stream is Special:Log/thing so it doesn't completely fail at slashes. But edits and creations of such titles seem not to be reported under any circumstances (watching, blacklisting) by the bot. Krinkle 23:22, 28 May 2010 (UTC)
  > > Further at JIRA. Krinkle 13:52, 3 June 2010 (UTC)

Page protection-action is not reported

I've been curious about this one, but AlexZ told me the bot did supported it but it was either never enabled or commented out. I found in RCReader.cs it does have a case in the switch() for protect on line 255 (SWMT 1.18). But when on line 424 it's sent to the Program.cs: Program.ReactToRCEvent(rce); it goes wrong.

in ReactToRCEvent() there is a switch (r.eventtype) on line 864 in Program.cs but it doesn't have a case for protect yet, so that should be added in order to make that work. Krinkle 23:36, 28 May 2010 (UTC)

Autoblacklist overrides current listing regardless

It seems that currently (SWMTBot 1.19) the bot blacklists a blocked user, no matter what, for 96 hours. I heard (and expected) it to only globally blacklist a user if the user isn't listed already and if not, add for twice the duration of the block. But a quick dive in the code revealed it. Program.cs :: Line 1043

(..)
case RCEvent.EventType.block:
          attribs.Add("ipcat", "");
          attribs.Add("blockname", ((Project)prjlist[r.project]).interwikiLink + r.title);
          attribs.Add("editor", ((Project)prjlist[r.project]).interwikiLink + "User:" + r.user);
          attribs.Add("length", r.blockLength);
          attribs.Add("reason", r.comment);
          message = getMessage(5400, ref attribs);
          //If the blocked user (r.title) isn't botlisted, add to blacklist
          if (listman.classifyEditor(r.title.Split(new char[1] { ':' }, 2)[1], r.project) != ListManager.UserType.bot)
          {
              //If this isn't an indefinite/infinite block, add to blacklist
              //Since we're in the RCReader thread, and we'll be writing to the db, we better open a new connection
              IDbConnection rcdbcon = (IDbConnection)new SqliteConnection(listman.connectionString);
              rcdbcon.Open();
              if ((r.blockLength.ToLower() != "indefinite") && (r.blockLength.ToLower() != "infinite"))
              {                                                               //345,600 seconds = 96 hours
                  int listLen = Convert.ToInt32(SWMTUtils.ParseDateTimeLength(r.blockLength, 345600) * 2.5);
                  string blComment = "Autoblacklist: " + r.comment + " on " + r.project;
                  message += "\n" + listman.addUserToList(r.title.Split(new char[1] { ':' }, 2)[1], "" //Global bl
                      , ListManager.UserType.blacklisted, r.user, blComment , listLen, ref rcdbcon);
                  Broadcast("BL", "ADD", r.title.Split(new char[1] { ':' }, 2)[1], listLen, blComment, r.user);
              }
          (..)

Though I'm not exactly sure if it's possible, I think it'd be handy to have an else{}~ in there that will blacklist indefinitly, and within the if(!=indefinitly){} a quick calculation of blacklist duration = block-duration * 2 and request to the db of the current blacklisting. if the proposed blacklist duration is longer, update it. If not, leave the current listing be. Krinkle 13:45, 31 May 2010 (UTC)

Correction: I've re-read the code and the bot tries to extract the block duration with SWMTUtils.ParseDateTimeLength(); which converts stuff like "2 weeks" or "1 day" to actuall number of seconds for blacklisting (* 2.5). However, I drew my conclusions in #cvn-wp-nl, which monitors the Dutch Wikipedia and it so happends to be that MediaWiki reports localized words in the blockduration on irc.wikimedia.org. So the bot is unable to figure out the blockduration for non-Engish wikis and thuss defaults to 96 hours. Maybe ParseDateTimeLength() can get the time-words (eg. "day", "year", "minutes") from the MediaWiki-namespace at the wiki ? Either way, that's less important, the check to avoid overriding an 'indefinite' blacklist with an expiring one is more important imho. Krinkle 17:20, 31 May 2010 (UTC)

Bug reports

Since we have an actual bug tracker, feel free to use it.  — mikelifeguard@meta:~$  03:26, 1 June 2010 (UTC)

Oh sure, didn't know that ;) Krinkle 13:40, 3 June 2010 (UTC)

The bug report tracker link posted above seems to have become obsolete and is currently out of order. Is there a link to the new bug tracker (if one exists that is)? Megabits13 (talk) 23:38, 6 September 2023 (UTC)