💡 Auto-thread prerequisites

[n1ckoates]

Describe the improvement

A way to select requirements that a message must pass for it to be auto-threaded.

For example, a server might want to only auto-thread on messages that contain a link, or have a keyword, or are from a specific user or bot (#61).

I'm not exactly sure how this should be implemented. The string option only allows selecting one choice, and this would probably work best as a dropdown. We might be able to use modals or a dropdown message component.

Problems this improvement solves

In one of the Discord servers I'm in, we have a news channel, where members post links to news articles. Needle is setup to auto-thread messages in this channel. However, other messages are sometimes sent in this channel, so it'd be nice to only auto-thread on messages that post an article.

Alternative solutions

No response

[n1ckoates]

After thinking about this a bit more, I have an idea for the command structure.

/configure requirements would be the base sub-command.

• channel - The channel to edit options for.
• role - A role the user must have.
• user - A user the message must be sent by.
• keyword - A keyword the message must have.
• link - Whether the message must have a link.
• embed - Whether the message must have an embed.
• bot - Whether the message must be sent by a bot.

A message would only be auto-threaded if all of the requirements passed, not just any.

[luniks]

Nice feature 👍

It would be great to have also a number of answer as prerequisites! Discord already suggest to create a thread when a chain of 3 replies occurred :

[MarcusOtter]

@luniks I think this feature would just apply to channels with auto-threading enabled. Those channels shouldn't have a chain of replies as each message would create a new thread.

[luniks]

Hello @MarcusOtter!

Thanks for your feedback. Perhaps I misunderstood the topic of this issue. My guest was having the possibility to add conditional rules on how the auto-thread process is triggered (for exemple : a certain role of a user).

So the basic idea is to create a new thread only on specific use cases, and a chain of replies could be one of them for me. For sure with this configuration, the auto-threading would become the exception and not the usual case ;)

But maybe I missed something or their is some technical constraints I am not aware of. Please let me known!

[MarcusOtter]

Right, I think I was distracted when I read your original message and misunderstood. Sorry about that! Amount of replies definitely makes sense. Might be a bit tricky to figure out implementation-wise but shouldn't be impossible :)

[MarcusOtter]

We could make this feel more like Discord's search feature where you can have a dropdown with options for fields like this (and the ones you mentioned previously):

This would make it easier for people to select which sort of attachment they want to require. Discord's search function allows to filter by link, embed, file, image, sound, video, and sticker. Not sure if all of those are programmatically easy to determine but just throwing the idea out there :)

[Maikel1990]

Any update on this? Would be very nice if this is implented for a suggestion channel for example.

[goodideagiver]

Consider adding option to block discord respond feature.

In this scenario:

The bot could delete responding message because user should respond in a thread.

[MarcusOtter]

I think we should make it configurable on what actually happens when the prerequisites are not fulfilled, something like

• Do nothing (no thread)
• Delete message
• Timeout user
• etc

[Snailedlt]

@nchristopher great idea, and lots of neat arguments too! To add to the arguments we could have

• match - A regex which the message must match

[MarcusOtter]

A regex option would be cool - but we need to make sure that we do it safely (there are regexes that can be constructed to be very very slow or hang the program).

[Snailedlt]

This might be useful then: https://www.npmjs.com/package/safe-regex Never used it before, but seems legit with 19,516,070 weekly downloads

[YozoraXCII]

To follow up on this, the ability to exclude some of these criteria would make this feature a lot more powerful.

As an example, if I have Bot1, Bot2, Bot3 etc up to Bot10 and I want to exclude Bot10 from creating a thread, it is much simpler to say "user is not Bot10" than it is to say "User is Bot1 or User is Bot2 or User is bot3 etc through to Bot9".

[Snailedlt]

@YozoraXCII yes, this 100%!

Just adding a not operator should be fine, that way you can have a list as an input. Having AND and OR operators too would make the solution a lot more powerful.

For example: user: (@12345678 AND NOT @1245599283) OR @8489185772`

AND, OR and NOT can also be replaced by symbols if you want.

AND = && OR = || NOT = !

[MarcusOtter]

The implementation would likely be something like two parameters includeUsers and excludeUsers that can take a role or user mention. If there is overlap between them, the exclude should "win". That way we don't force normal users to write boolean logic in a raw string without any help, and instead take advantage of the built-in parameter types in Discord which gives them a dropdown. This makes for better UX:

[Snailedlt]

It is more verbose for sure, but much less powerful. Could we also get an alternative implementation with Boolean expressions supported?

[MarcusOtter]

I think the user experience for the average person is more important than the very very high configurability for the more technical-minded software people. When we start adding boolean logic and scripting to the bot it's better to just let people fork it and run their own versions of commands. So I don't see myself adding something like that, sorry.

EDIT: Not to mention how much more complex some sort of scripting logic would be to implement, and a key design goal of this bot is to keep it as simple as possible.

[Snailedlt]

Okey, fair point :) Guess we can always fork if we want more advanced functionality

[auwsom]

@MarcusOtter ( @luniks ) If I want to fork this to add Auto-thread option after X messages, could you point me in the right direction?..

I assume the settings are stored in this file (for example includebots): https://github.com/MarcusOtter/discord-needle/blob/ee1e7174fcca94aa36d29b319883157360180dac/src/models/AutothreadChannelConfig.ts#L28

And created by this file: https://github.com/MarcusOtter/discord-needle/blob/ee1e7174fcca94aa36d29b319883157360180dac/src/commands/auto-thread.ts#L207

And then the thread creation is checked with "shouldHaveThread": https://github.com/MarcusOtter/discord-needle/blob/ee1e7174fcca94aa36d29b319883157360180dac/src/services/ThreadCreationService.ts#L58

I just noticed the comment "// In the future if we have prerequisites we need to check those here", so I assume this is where you imagined putting this.. https://github.com/MarcusOtter/discord-needle/blob/ee1e7174fcca94aa36d29b319883157360180dac/src/eventListeners/ready.ts#L73

So I would need some logic in a listener like "if latestTenMessages has only 2 users, then allow thread creation"?

Thanks for any input you have. Cheers

PS: I'm leaning toward a thread being created only when a "reply" is used. This should simplify everything.

[auwsom]

I think all I need to change is above if (!lastMessage) continue; add if (lastMessage != REPLY) continue;.

I'm not sure yet how to check if lastMessage is a reply.

According to https://stackoverflow.com/questions/67032774/detect-if-message-is-a-reply, the MessageType can be checked for Reply. https://discord-api-types.dev/api/discord-api-types-v10/enum/MessageType#Reply

I think it should be: if (lastMessage.type != "Reply") continue;

https://old.discordjs.dev/#/docs/discord.js/main/class/Message?scrollTo=type https://github.com/discordjs/discord-api-types/blob/main/payloads/v10/channel.ts#L698

[auwsom]

Okay, I've forked and made a single line patch from my last message. Testing now. https://github.com/auwsom/discord-needle-reply

Parking a couple of feature requests from Discord Support. Apparently, this is how Slack works by default. https://support.discord.com/hc/en-us/community/posts/4405451136535-Creating-threads https://support.discord.com/hc/en-us/community/posts/4405186575639-Auto-create-threads-in-announcement-channels

[auwsom]

Sweet, it works! @luniks https://github.com/auwsom/discord-needle-reply.git

Only two lines were changed. In discord-needle/src/services/ThreadCreationService.ts, import { MessageType } from "discord.js"; was added on line 35, and if (message.type != MessageType.Reply) return false; was added on line 69.

[auwsom]

@MarcusOtter Hey Marcus, I'm going to add this issue as a solution to the Discord Support feature request pages above. Slack is set up this way by default, and it really cuts down the clutter. It would be great to add this to your repo, so people don't have to use my forked version, and can use your website bot invite.

Thanks for making this repo! This feature is a big deal for me using Discord and keeping it organized.

Like this comment if you want to see this in Marcus's Needle.

[auwsom]

You can use this bot I'm hosting for the time-being. Or you can host your own in GCP: https://discord.com/api/oauth2/authorize?client_id=1110757452032520264&permissions=326417517568&scope=bot

btw, the bot command to turn it on is /auto-thread on and needs to be done per channel, afaik. also , the GCP Debian and Ubuntu images have old version 12 of nodejs. Install 18 with curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - &&sudo apt-get install -y nodejs. It comes with Npm.

[MarcusOtter]

@auwsom Thanks for looking into some of this stuff. Your version seems to make sure that Needle never creates a thread if it is a reply, which is also an interesting aspect we might consider for this prerequisites feature in the future. It will not be merged into the main repo as-is because that would be a big breaking change for everyone and is also not supposed to be the default behavior - it needs to be configurable. But the idea is there, so thank you for showing that it is possible!

[auwsom]

@MarcusOtter sure, no problem.. just to be clear, it makes a thread only when the reply is used. This is how Slack is by default. Maybe we can make it an option.

[Junebugging]

I think the user experience for the average person is more important than the very very high configurability for the more technical-minded software people. When we start adding boolean logic and scripting to the bot it's better to just let people fork it and run their own versions of commands. So I don't see myself adding something like that, sorry.

Agree with this, and this issue has been up for over a year now, it'd be far better to have a rudamentory version of this feature soon, than to wait another year to implement a more complex version of it.

[Junebugging]

If someone could point me to where in code the messages are intercepted and read, I could create a branch and try to begin implementing this

[auwsom]

@Junebugging check out my code (and some details in my comments above) I'll repost the link to my fork here in a second.. https://github.com/auwsom/discord-needle-reply

One thing i wanted to check when using it in Discord is that it creates "a subtopic" for each thread in the left side bar. I'm not sure how Slack handles that.

[MarcusOtter]

I appreciate the enthusiasm here and I recognize that this is the most commonly requested feature by far. I don't have a lot of time to work on this bot so that's why progress has been lacking.

For me, the main hurdle right now is the UX. What would configuration of this look like? It needs to be very generalizable and easy for us to add more requirements down the line. And it needs to be very clear to the user how it works. The best way would be if we could configuration of this to /auto-thread in some way (since that's how all other settings of auto-threading behavior is handled), but I think the amount of parameters would be very overwhelming (and I think there's even a hard limit of how many parameters we can have for one command).

Some things we still need to figure out:

• What happens when multiple prerequisites are provided? Should it be that ALL need to be fulfilled, or at least ONE? Should this be configurable?
• How do we deal with negations? I.e. only create threads if you have this role VS only avoid threads if you have this role (same goes for all prerequisites).
• This kind of ties into the previous bullet, but what if you want more advanced prereqs like:
  • by default, do not create thread
  • if user has member role, create thread
  • if user has moderator role, do not create thread

I don't have good answers for these