@Glorfindel The !!/blacklist command has been deprecated. Please use !!/blacklist-website, !!/blacklist-username, !!/blacklist-keyword, or perhaps !!/watch-keyword. Remember to escape dots in URLs using \.
@Glorfindel That pattern looks like it's already caught by Few unique characters in answer and Few unique characters in bodyThe pattern contains an invisible U+202D whitespace character. Append -force to the command word(s) if you really want to add the pattern you provided.
@tripleee Post 1: That does not look like a valid post URL.
@tripleee The regex contains an unescaped ".", which should be "\." in most cases. Append -force to the command word(s) if you really want to add the pattern you provided.
@tripleee That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
Ahhh, yeah, there's nothing we can do about it in chat, unfortunately. Well, we could have FIRE and/or AIM process the chat message further in order to use <bdi> instead. I've already been contemplating one of those do even more processing for other reasons, so adding that should be fairly easy.
@tripleee That pattern may be a North American number. If it is, please use a format which starts with an optional 1 followed by possible separator text and has the main number in the format 776-402-7283 where - could be a single alpha character or any [\W_]*+. Alternately, you can add the comment (?#IS NorAm) to the end of the pattern to force also using the alternate normalized form, or (?#NO NorAm) if it's not a North American phone number and it's incorrectly recognized as one. Perhaps try !!/blacklist-number 776-402-7283. Append -force to the command word(s) if you really want to add the pattern you provided.
@Glorfindel MS should be completely switched over to using <bdi></bdi>, so it shouldn't have come from MS. If there's still a use, I'd like to know so I can fix it.
For chat, <bdi> elements are stripped when included in the chat message source, so there's nothing that can be done when posting the chat message, other than use the override characters. It could be manipulated by a userscript in chat to change all instances to <bdi>, but that's about all that could be done. However, that seems like a good idea. I seem to recall previously thinking about doing that, but haven't implemented it.
@Makyen Last time we chatted about stripping out erroneous whitespace and/or warning about it, it was for preceding whitespace, and you had mentioned back then that you wanted to take a look at multiple rejection reasons. I mention this because you seem interested in looking into this and I figured I'd remind you about your thoughts back then.
I can't believe it's almost been 2 years since then.
Upon review, those rejections look like they could use a refactor...
@Spevacus I'm not against that, but it already seems relatively separated and easy to add/remove additional checks. Sure, each check could go in it's own separate function. The phone number stuff is sufficiently complex such that it probably should be in a separate function, assuming there aren't too many dependencies on the state elsewhere in the main function.
IIRC, the issues I was talking about back then were largely dealt with when the phone number code was added. Each "issue", now, is just appended to other_issues and formatted consistently at the end. Adding most new checks can be as simple as adding a single if statement and a other_issues.append("This is why you would need to use -force to do this").
@CesarM Something that would help is if we could find out the exact difference between the data provided by a "safe" vs an "unsafe" filter. Is the processing SE uses only HTML escaping the text?
@Makyen tbh I'm not sure I understand the issue / question fully, can you email safety@ with something I can forward to dev folks and I'll get back to you once I have an answer?
@tripleee That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
@tripleee That's something that might vary by site. On SO, we prefer that an "in need of moderator intervention" flag, not a plagiarism flag, is used for ChatGPT posts. Effectively, there's a substantial difference in processing plagiarism vs ChatGPT, with ChatGPT flags generally being much easier (e.g. you don't have to even thing about going through posts that are older than 2022-11-30).
Y'all, the string changes to the titles should have recently been reverted so the old strings will work again. Please let me know if you're still having any issues.
The change broke all flagging through MS. I pushed a change to MS yesterday which should work with both the old and new (and now the reverted old) values. For the released version of FIRE, the issue was entirely within MS, so the same change should be working.
[ SmokeDetector | MS ] Bad keyword in body, bad keyword with email in body, bad phone number in body, blacklisted website in body, potentially bad ip for hostname in body, +1 more (349): HOW TO RECOVER FROM BIG LOSSES by Colin Jessie on bitcoin.SE
@K.Dᴀᴠɪs An autoflag of yours was used on this post [MS], which is FP. It would be good if you could evaluate it for yourself and determine if you want to retract the flag.)
!!/report stackoverflow.com/a/75788759 "Trolling ('i was being sarcastic' in comments, question is asking how to get property names as strings, answer sarcastically just prints those exact strings as literals)"
