[00:34:35] moonmoon: sounds like you have grounds to me. Banned in other venues generally makes it an easier sell (for better or worse) [00:35:27] if a temp ban resulted in the same behavior that's another strong data point [00:46:45] it hasn't been too bad so far [00:47:31] nevertheless, it's 'interesting' how he managed to misspell the group names, adding a trailing space (plus the "syosp" typo) [00:53:11] Platonides: it's mostly the patterns imo. each individual interaction is fairly benign, but the pattern emerges where he receives help (after much tooth-pulling to get any info usually, see the CentralAuth things from yesterday or the channel logs for 2024-10-11, 10-15, 10-19, 10-21 all covering the **same exact issue**) [00:54:00] er, I missed the last half of the sentence. he receives help, but then seemingly doesn't understand or comprehend it, then finds himself in the exact same situation months later without any ideas of what to do or where to go [00:55:59] that all being said, I'm fairly biased due to being extremely tired of this from elsewhere (the mediawiki discord), so I didn't want to unilaterally impose a ban in case that was my bias speaking rather than the general sentiment of the channel/community [00:59:39] sure, I was only considering his last two interactions here [01:00:07] I didn't remember him from October (maybe I wasn't looking at the channel?) [01:00:47] and I understand how you could be fed up from another venue, already [01:00:54] previous IRC ban was 2023-06-15 to 2023-09-07 (#9988 in litharge) [01:02:29] (at least, that's the one in my logs, I can't seem to query litharge properly) [01:02:55] hmm [01:03:05] I'm not even sure how to query that [01:04:34] /msg litharge query --channel=#mediawiki term [01:05:03] and /msg litharge info id if you want more details on a specific hit [01:05:58] ok, that's /msg litharge info 9988 [01:07:17] a shadow-ban would be as effective, though? just put them on /ignore. [01:09:56] bans by p858snake #14445 and #14464 seem to be directed to the same user [01:15:11] kjetilho, collective action problem. we've got an unending (but extremely finite) number of helpful folks here who don't realize how much time wasting they're signing up for [01:17:24] Yes I've done at least twice for the user [01:22:05] Can someone post on their talk page pointing to the support desk or something? [18:10:50] Not sure if this a ReplaceText bug or what, but I had a staff member report that doing a regex to find {{p\|(.*)}} and replace it with $1 causes an error. I checked on a vanilla install and found that it does indeed. I don't THINK this is a bad regex, but I usually use cheatsheets when I build them, so I'm not sure. [18:11:25] Also strange that it would throw an error at all even if it is a bad regex. It's the actual DB query that's getting an error. [18:16:26] https://pastebin.com/eGVZx8tK <- full stack trace + error [18:36:52] I didn't know it passes regexp to the db layer these days. I'm sure the db regex engine is more limited than what php supports and in that sense it not surprising... but those errors should be caught in a better way [19:00:53] jfolv: {} are special characters and need to be escaped [19:09:49] Yep, escaping them did the trick. Still might be worth filing a ticket about that error behavior, though. [19:10:15] Maybe the regex could validating before sending so it doesn't return a DB error. Those always look particularly ugly. [19:10:31] *could be validated [19:21:56] maybe we could use a regex to validate the regex /sarcasm