Daniil-SD

user435118

08:11

@Makyen ping ^

user435118

19:22

@Makyen ping

user435118

So how can I append some text (preferably some bold formatting/links but not needed) to FIRE

Makyen

19:42

@Daniil It sounds like you're wanting to add HTML text. That's easy to do in both jQuery and vanilla JavaScript. There is a difference in using the two. The biggest difference is a security issue. When using vanilla JavaScript to add HTML text to the DOM, any <script> tags are intentionally disabled as a security feature, which is a good thing.

When using jQuery, it programs around this and explicitly makes <script> tags active. So, never use jQuery to add HTML text to the DOM which wasn't completely sourced by you.

My go-to method for adding HTML text to the DOM using vanilla JavaScript is insertAdjacentHTML().

With jQuery, there are several different methods, depending on where you're placing the new text/elements: inside, outside (which are mostly functional-equivalent to the options to insertAdjacentHTML(), .textContent and .innerHTML).

user435118

19:57

What’s the element I want to insert to? @Makyen

Makyen

@Daniil That's not an easy thing to answer. It's going to depend on what you want the text to look like. I suggest using the browser's inspector and trying some things to see what gets you what you want.

Makyen

20:17

@Daniil Alternately, we can change FIRE such that there is a specific element which you can add to, but that doesn't exist yet.

user435118

20:32

@Makyen Would that be hard for you to change?

Makyen

20:57

@Daniil Probably not.

user435118

@Makyen Could you change it at some point relatively soon? Or are you busy atm

Makyen

@Daniil I'll try to put it in the update I've had queued for the last couple of weeks. I've actually had updates for FIRE, AIM, and userscript dependencies queued up and mostly tested for some time now, but my available time keeps being used elsewhere. The FIRE update still needs some work wrt. testing and determining what-all of the changes I have is actually going to be in the update.

@Daniil The issue with leaking the GitHub password in response to !!/errorlogs should be resolved (and any potential issue with leaking the Chat password). Those values should now be redacted when: prior to them being stored in the errorlog database, when read from the database, prior to being output to the console log, and prior to being output to the error file.

Please update your SD fork to the current commit and git rebase any code you've been working on (or other appropriate method of using SD's current code).

user435118

21:23

@Makyen I’ll do that tomorrow, thanks. Didn’t get to working on much code yet

user435118

@Makyen What changes are planned for FIRE? Can I get the new version of FIRE when you implement a specific element (even if it isn’t for wider use yet)? When do you plan to release the update?

Makyen

@Daniil I'd planned on releasing the update about two weeks ago. :(

It's non-trivial to give you access to current code, mostly due to how the version I use and develop on diverged about two years ago when I wasn't permitted to merge in the ability to flag through the SE API. It means that at this point there are very large differences between the version I use and the released version. The update I'd planned included integrating some of the changes I'd made.

While I'm now permitted to add flagging through the SE API, that probably won't be in the next version, because there are some issues that need to be stepped through first.

user435118

Oh, so we flag through MS right now?

user435118

So I guess I’ll do the other parts of my userscript or just scrap it completely

user435118

21:39

I’ll probably just delay it for a considerable amount of time. I’m getting busier next week (since I’m partially going back to school)

user435118

@Makyen ^

Makyen

@Daniil Yes, FIRE is strictly through the MS API for flagging, at the moment.

@Daniil It was not my intention to imply that you should scrap what you are doing. While what you are doing is close to things I'd considered adding, it's not something I've worked on (other than a personal userscript that formats !!/watch commands from text already placed in the chat input textarea and separated into one thing to watch per line). So, it has not seemed that what you're working on would be redundant.

@Daniil It doesn't seem that what you're wanting to do would need to be delayed, unless that's what works for your schedule. You should be able to prototype and move forward, even without any changes to the released version of FIRE.

user435118

22:55

Were my blacklisting/core privileges granted based on my activity at that time? If so my core and blacklisting? privileges may have to be removed. Since my return to school starting from next week, my activity is going to be slowly declining. I used to be in here 5 mornings a week, it’s going to be 4 from next week and 3 towards the end of July. By September, I predict my activity will be down to what it was at the beginning of March (0 mornings a week but a few evenings, ~15% of what it is now)

user435118

@Makyen ^

Makyen

@Daniil Largely, removing those permissions is rare. Core may be removed if you have no activity for an extended period of time, or if you tell us you're going to be less available. That isn't because the permissions are intended to be withdrawn, but because having the Core role also grants a higher probability of your account being picked for autoflagging.

The primary reason for giving more autoflags to "core" people is that people in the "core" group tend to be around chat much more than people who aren't in that group. Having people substantially more available in chat is beneficial, because they are more likely to be around to respond to a notification of a FP feedback on an autoflagged post. Thus, they are much more likely to rapidly see the chat notification and evaluate the post for themselves, retracting the flag if appropriate.

That's not all that "Core" is about, but it's a substantial consequence of how the role and autoflagging are set up, and a reason the "Core" role may be withdrawn during periods of inactivity.

user435118

23:11

So will my core privileges be removed? @Makyen

Makyen

@Daniil That's not a question I can directly answer, because it requires prognosticating about the future. I'd say let's see how it goes. Something that would make it much less likely is you letting us know that you have set your autoflagging conditions to not be much more aggressive than the defaults. While I can check what your setting currently are, I have not done so (i.e. that may be the way they are already set).

My primary concern about leaving Core active for someone who isn't around a lot is, as I've mentioned, them not being around to evaluate FP feedback on autoflagged posts. If your autoflagging conditions are set conservatively (e.g. just turn off any that are aggressive), then that's really not much of a consideration.

There was a period of time where "Core" was granted automatically, and removed automatically, based on the user maintaining a minimum number of feedbacks in the last N time. However, doing that automatically caused various usability problems and was removed not too long after it was instituted.

user435118

23:36

My condition is:

user435118

Minimum Weight Maximum Poster Rep Minimum Reason Count Sites
140 1 3 175

user435118

@Makyen Is that too ‘weak’?

Makyen

@Daniil Compared to the default of weight being 280, that flagging condition is quite aggressive.

Transcript for