@JeffSchaller 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 762-482-1974 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 !!/watch-number 762-482-1974. Append -force to the command word(s) if you really want to add the pattern you provided.
@JeffSchaller @JeffSchaller: if you really think it makes a difference to exclude support.ezoic.com we could do something like (?<!support\.)ezoic\.com
@Makyen 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 \.
@Makyen A normalized version, {{'7624821974'}}, of that pattern is already on the number watchlist and the pattern you provided is not an exact match to an existing entry on the number watchlist. You can use !!/bisect-number 7624821974(?#no noram) to determine which entries on the number lists match that pattern, which would tell you: Matched by 7624821974(?#NO NorAm) on line 4278 of watched_numbers.txt: 7624821974 found verbatim
@Fastnlight That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in bodyThe 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.
@Fastnlight That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command word(s) if you really want to add the pattern you provided.
The thing which was causing there to be such a long delay between when a post was reported and when autoflags were raised was the query to determine the approximate historical accuracy of the current post's weight in order to scale the number of autoflags. When the number of red flags to delete a post was 6, this was used to determine if the maximum number of automatic flags to be raised would be 3 or 4 autoflags.
Since the change, almost a year ago, to needing only 4 red flags to delete a post, the results of that query have, effectively, not been used and the maximum number of autoflags has always been 3, unless lower than that based on there being only one person with a matching autoflagging condition or the maximum number of autoflags was set lower for that particular site.
Given that we've been operating without that scaling of the maximum number of autoflags for nearly a year now, I made a change in MS' configuration which disabled the code which scaled the number of autoflags. This prevents that query from being made, dramatically reducing the time between when a post is reported and the autoflags are raised.
