@angussidney Cool. I'll take a look at it. I haven't tried AIM. I've another userscript, for SOCVR, which shrinks and fades completed requests (including SD Reports for deleted posts). Sounds like those two scripts may have chosen to do something visually similar. I'll take a look at AIM and any proposed changes to FIRE will remain compatible. Currently, I wasn't planing anything dramatic, just changing the emoji used in the report based on status and adding a tooltip with abbreviated info.
However, the intent is to have any such change be useful. Thus, I'm fully open to alternatives, including not making a change. Let me take a look at what AIM does and see what might fit. Thanks for mentioning it.
@Makyen changing the emoji sounds good. AIM doesn't do that. Not sure if FIRE will accept another emoji as a trigger to open the post details, but I guess you'd look at that too :)
@ArtOfCode Yeah, that part works fine (at least as far as FIRE and the SOCVR script). It's just a DOM node with a class (a <span class="fire-button"> with everything inside as the button). The contents of the <span> don't matter to FIRE. Yeah, given that I already have a script that fades & shrinks "completed" requests, I wasn't looking for something that made a dramatic change. Mostly I was wanting something that stopped drawing my eye towards the FIRE emoji :-), even when faded & shunk.
@JF That could work. I'm open to suggestions. Currently, it changes the emoji on reports which you've provided feedback and flagged to a 🚒 (fire engine); posts which have sufficient feedback are changed to a 💧 (water droplet) and ones for posts which are deleted have the background around the emoji changed to the standard "deleted" color. A standard browser-tooltip is added showing the feedbacks, your action, and if deleted. I'm completely open to whatever works for everyone.
@ArtOfCode With respect to keeping status updated, how concerned should I be about generating API traffic on MS? Obviously, we don't want to gratuitously hit MS with a large number of API requests. With current changes, FIRE only updates status when the user does a mouse-over of the emoji, and then only if the current data has become invalid due to user action (or 5 minutes has expired from the last update). However, some amount of automatic status updates of non-complete posts would help.
@ArtOfCode I'll look into it. I'd prefer not to poll, but hadn't, yet, searched for other interfaces. FIRE doesn't currently do anything wrt. automatically keeping the data updated. There's some code, but it's commented out. Everything is currently based on the user clicking/mouse-over the emoji.
@Makyen Aye, which happens just about regularly enough that that's okay, but obviously not if you want live updates. The WS API is the only live-update interface to MS there is, so it's either that or polling I'm afraid :)
@ArtOfCode Hey, having something is a lot better than not having anything at all. Just from your brief description it sounds like it includes the most important information. Should be good. I was assuming the best I'd get is a limited poll of still active reports.
@Makyen The WS API has basically everything available, but you've gotta know metasmoke pretty well to know what you're actually looking for. Technically, you can receive messages for a create or update of any instance of any model. Knowing when model instances are created or updated is the not-so-easy bit
but hey, that's what the ole walking talking documentation is for
@ArtOfCode It looks like it might take some time to become familiar with the API. Walking, talking documentation works (usually), but does have known drawbacks :-) and benefits. I'll look into using websockets, as it's the superior solution for real-time/near real-time updates. However, I'll probably put it into a later version. For right now, it's probably better for me to wrap up what's already mostly done, as I have other scripts which I feel obligated to move towards release.
@ArtOfCode BTW: Is there any way to, with 100% certainty, match an SD report posted in chat with an MS postId? In some instances, the URL is not unique. FIRE currently punts when there's more than one postId associated with a URL (it uses the most recent report). While I can work around this with a reasonably high confidence, there are some corner cases which would be difficult to determine.
@Makyen Just the URL is reasonable confidence, but we do get duplicates. You can get pretty accurate if you match the message timestamp with the MS timestamp (with a tolerance, obviously), but that's still not absolutely 100% - very very occasionally we've had duplicate reports at the same time.
@ArtOfCode That's about what I had figured, along with the potential that the post title might be different in the multiple reports for a URL. I add a posting timestamp to the chat messages in the other script I mentioned & expected I could get a higher confidence based on adding one via FIRE (for messages FIRE sees posted). Under most conditions, FIRE can just track the order that reports are posted for the URL. Some corner cases exist when FIRE doesn't see all reports for the URL.
@ArtOfCode It doesn't seem like it would be that difficult to include the MS postId in the SD report (e.g. as a tooltip for the MS link). But, I haven't looked at the code that posts SD reports to chat to see if the post ID is even available to that code/at that time. I'll just go with what gives a reasonable confidence under most conditions.
Could have an API call from smokey to get a reports count for the post URL, and include that in smokey messages. That combined with the URL would be a unique index
Can anyone explain to me why command("!!/alive") { say "Yep, alive and well" } is not the same as command "!!/alive" { say "Yep, alive and well" }? The second one throws syntax error, unexpected '{', expecting keyword_end (command is a method)
Just a minute, I'm trying to piss off Google and see if we have a rate limit. It's not looking like anything Travis would hit though. I just hit that shortened URL 200 times in rapid succession without a problem
@quartata No, for the time being, let's leave it so that we can actually fix it. Fixing the test looks pretty simple...pass two more parameters (GET and True), but we should try to figure out why Travis is getting an HTTP 405 response while we do not locally
[ SmokeDetector | MS ] Bad NS for domain in body, bad keyword in body, bad keyword in title, blacklisted website in body, link at end of body, +1 more: Jouliage cream reviews by vereuinerel on meta.SE
[ SmokeDetector | MS ] Bad NS for domain in body, bad keyword in body, bad keyword in title, blacklisted website in body, pattern-matching website in body, +1 more: excessive amount of muscle because by hamrodbez24 on graphicdesign.SE (@HenryWHHackv2.1)
[ SmokeDetector | MS ] Bad keyword in body, bad pattern in URL body, blacklisted website in body, link at end of body, pattern-matching website in body, +1 more: What Does Maxx Boost Do? by gnaxcarter on meta.SE
[ SmokeDetector | MS ] Bad NS for domain in body, bad NS for domain in title, bad keyword in body, bad keyword in title, potentially bad keyword in body, +1 more: www.wellness4healthy.com/jouliage-cream/ by Todeisler on askubuntu.com (@ThomasWard @quartata)
@Glorfindel That pattern looks like it's already caught by Bad ns for domain in answer and Bad ns for domain in body; append -force if you really want to do that.
