Jump to content


Add topic
From Meta, a Wikimedia project coordination wiki
Latest comment: 10 months ago by Megabits13 in topic Bug reports

Slashes in titles


I've confirmed in several channels (#cvn-wp-enconnect and #cvn-wp-nlconnect) 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)Reply

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)Reply
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)

[[User talk:]] http://en.wikipedia.org/w/index.php?diff=364691190&oldid=364691134 * * (+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)Reply

AFAICT, the (?<title>.+?) part is what captures the page title, and it is correct.  — mikelifeguard@meta:~$  22:10, 28 May 2010 (UTC)Reply
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)Reply
  > > Further at JIRA. Krinkle 13:52, 3 June 2010 (UTC)Reply

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)Reply

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);
              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)Reply

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)Reply

Bug reports


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

Oh sure, didn't know that ;) Krinkle 13:40, 3 June 2010 (UTC)Reply
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)Reply