@Jesse It is. Long standing troll on WB. Came back recently and a mod wiped their account. Seems they are currently on a campaign to to harass the mod.
@JamesRisner ╳ You are not a privileged user. Please see the privileges wiki page for information on what privileges are and what is expected of privileged users.
@cocomac Correct. Job offers are considered spam. Generally, I won't impose the normal spam penalties on users who post them without clear evidence of bad faith, but they're still red-flaggable by users, and they're definitely still TP for the purposes of MS feedback.
@SmokeDetector The MS link here is returning a "502: Bad Gateway" error for me.
@cocomac 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.
@cocomac 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.
@JamesRisner I've added you to the privilege list for SmokeDetector (SD) here in Charcoal HQ, which also applies to several other rooms. You should run the !!/amiprivileged command to verify. It would be a good idea to read through the Feedback Guidance, SmokeDetector wiki, and SmokeDetector commands (in particular feedback).
If you haven't already read it, there's an Introduction to Participating in Charcoal. You may have already seen that introduction and some of the other things linked here, but this wall of text puts several of them in one place.
You may also want to look at the userscripts we have available (GitHub), as they can be quite helpful, depending on how you want to participate. For viewing, feedback, and flagging in chat, I find FIRE and AIM to be the ones I use the most. I also find SIM (install) convenient.
For flagging through the userscripts, your metasmoke account needs to be write authenticated with SE, which, if you haven't already done so, can be done from the authentication page and doesn't require you to also sign up for autoflagging, although authenticating is also a required step for signing up for autoflagging.
In addition, to enable manual flagging through the userscripts, the checkbox that says "Allow metasmoke to raise flags for my account" on this page also needs to be checked. If you have no entries in the "ID Site Count Flags Used Today" list at the bottom of that page, then autoflagging will still not be enabled, but manual flagging through the userscripts will be enabled.
Just so you know, we normally tell people when they are getting privileges that we practice the "ton of bricks" discipline method here: If you mess-up sufficiently, or consistently, we come down like a ton of bricks :-).
To quote ArtOfCode: "TL;DR: ton-of-bricks is mostly to say that we almost never need to enforce things because things enforce themselves through having a good community here. If it gets to the point that someone's enforcing something, something's gone badly wrong."
Quoting NobodyNada [with a bit added]: "Note that 'mess up' doesn't mean 'make a mistake', it means 'do something intentionally irresponsible/antagonistic' [or consistently do something wrong and not change when it's, repeatedly, pointed out]. Charcoalers are generally quite friendly, forgiving of mistakes, and willing to help each other learn. We recognize that our systems and policies have quite the learning curve -- so don't be afraid of us :)"
^^ The script that posts that could be modified to combine at least some of it into a single message, since you know that you'll be replying to a message.
@CodyGray If I could do it all in one message and have paragraph breaks, that would be great. I just don't have a good way to do that. I'm willing to change it to make it fewer chat messages, but would prefer not have multiple pings for the user, but I guess a couple pings would be OK, if it provided real benefit. From my point of view, it's currently not much work to post it:
click reply to the message requesting access; search for the text in the doc with the collection of such messages; copy and paste it into chat; wait for the three messages from SD that are posted upon reboot; click "multi-part" button to start sending; do something else/wait for the messages to be sent.
I expect it's probably annoying to everyone else to have all of those messages posted back to back.
Yes, it takes up a large amount of space in the transcript. This is one of the cases where it being auto-collapsed would actually be very helpful, as the target recipient could expand it to read it, but everyone else could skip it because they know what it says.
@CodyGray That would be great, if there was a way to use Markdown in such messages. I'd like to preserve the ease for the user of being able to click on links, rather than having to manually highlight the URL text and manipulate them/the browser into opening the URL.
@tripleee 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.
@tripleee That pattern looks like it's already caught by Blacklisted website in body and Blacklisted website in answer Append -force to the command word(s) if you really want to add the pattern you provided.
@CodyGray I'm a bit confused. Using a long reply, which has Markdown support without paragraph breaks, doesn't collapse the message. It might be a bit shorter, because of not having paragraph breaks, but it's still going to be displayed in chat in its entirety, so doesn't accomplish what you said was the goal (collapsing the text). The only messages which are collapsed are actual multi-line messages, which do have paragraph breaks, but no Markdown formatting.
@Makyen Are you sure that using a long reply doesn't collapse the message? I'm relatively certain I've seen it collapse a message I've posted that way multiple times.
@CodyGray Yeah, it has some significant impacts on SD performance, some of which are easily noticeable, some aren't. I've got some ideas for how we can improve that, but haven't implemented them, yet.
@CodyGray Yes, that's one of the ways, which would be helpful, but there are some underlying issues which would be even more helpful to resolve having the actual changes not be as impactful.
@Mast Ah, well, let me introduce you to the different classifications: Expected expecteds, Expected unexpecteds, Unexpected expecteds, and Unexpected unexpecteds.
@cocomac There are two types of long chat messages. Long replies support Markdown, but don't collapse and don't have a way to have paragraph breaks, as far as we know at this time. Multi-line messages, which can also be a reply, do collapse, but don't support Markdown through the entire message.
@cigien 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.
@CodyGray There are at least a couple of ways to support that. One is to allow multi-line messages to have watch and blacklist commands one per line. Another would be to have SD look forward in the messages which have already been posted to see if another command for it has been posted and then combine the operations in a way that basically performs the individual additions, but delays the expensive operations until after each change is performed.
However, the primary gain in the overall process would really be obtained by making the process of reloading the watchlist and blacklist be vastly less computationally intensive. It's computationally intensive, because all the lists have to be fully recompiled into regexes each time, which can take 20 to 30 seconds. Currently, those regex recompiles are quite likely to be happening in multiple threads, with each thread duplicating the work.
My intent is to, within SD and not visible to the user wrt. the list handling, break the lists into at least two different regexes, with a main one containing most of the entries and one which is the last couple hundred entries (variable quantity), so there's a chunk that's long and rarely changed and a chunk that's much shorter and usually changed.
That, combined with both storing the compiled regexes across reboots and not recompiling each regex when the regex text hasn't changed, should result in that 20 to 30 seconds dropping to ~ 1 second in most cases.
Ah, that makes sense. And what would the performance costs be with respect to scanning when you have two different sets of compiled regexes to scan with?
@CodyGray There's relatively little performance cost to that. It would be a very significant issue if we broke it up into 40k separate regexes, but using just a couple regexes doesn't change the overall time to actually test the compiled regexes by much at all.
@cocomac ^ If a domain has apk in it, and SD says "That pattern looks like it's already caught by Potentially bad keyword in ...", you can bisect the domain to see if it's caught by the generic apk detection, and force the watch if so.
@SmokeDetector This appears to be AI generated. The machine translation when fed to huggingface says this is 99% fake. Regardless, the links is very obviously spam.
sdc report stackoverflow.com/a/75588685salesforce.stackexchange.com/a/378690 "User has 8 instances on the network linking to a site they're affiliated with (see profile), 3 on SO, 5 on Salesforce, with no disclosure anywhere. No other hits for the website on SE. Custom flagged on both sites. Reporting one from each site for a record on MS."
