Create embed persistance

[PatrickPedersen]

We want to ensure that the bot only creates the embed if no embed has been created already. Currently, it creates the embed on startup.

https://github.com/THE-BWC/DiscordOperationsBot/blob/edaf24560ce734446679d60746f30a617fc90d36/bot.py#L51-L80

[Goltred]

For the sake of curiosity... why is it that you want to have persistence on this? Wouldn't that cause other messages that come after it to push it up and then become lost in the history of a channel?

[PatrickPedersen]

My thought was only to have that one message there, which is updated dynamically (#2 ) It would prevent just filling a channel with op notifications that no one would look at, since it would be a mess of messages.

[Goltred]

I understand the idea, i'm just wondering about the chances that the message will become lost in everybody else's chatter... unless you plan to do this in a unique channel where no-one else can post to, at which point it might make more sense. That being said, then I would question a bit more the benefit of introducing this complexity in the codebase when maybe the solution could be different (maybe a command that prints out the upcoming ops, the a variation of the daily message that you are currently sending, or some sort of notification system that you can subscribe to for operations that you care about).

IMO, message persistence is extremely useful for other kind of things. For example the rapid response feature that is used in star citizen, where you could update the original message as required by interactions with the message, like having emotes that indicate if someone is going to answer it, or have an emote to cancel it and then modify the message accordingly so that it's clear that the thing is not required anymore.

[PatrickPedersen]

I understand the idea, i'm just wondering about the chances that the message will become lost in everybody else's chatter... unless you plan to do this in a unique channel where no-one else can post to, at which point it might make more sense.

That was my original thought.

That being said, then I would question a bit more the benefit of introducing this complexity in the codebase when maybe the solution could be different (maybe a command that prints out the upcoming ops, the a variation of the daily message that you are currently sending, or some sort of notification system that you can subscribe to for operations that you care about).

My experience so far, has shown me that if you don't throw it in the face of the people, then they either won't use it or request the same feature that already exists...

Keeping it to a dedicated channel, prevents the clutter in the other channels while giving us the option to tailor the messages to the exact format that we would want, without worrying about other messages or users getting in the way.

IMO, message persistence is extremely useful for other kind of things. For example the rapid response feature that is used in star citizen, where you could update the original message as required by interactions with the message, like having emotes that indicate if someone is going to answer it, or have an emote to cancel it and then modify the message accordingly so that it's clear that the thing is not required anymore.

Well, if I recall correctly, the way they submit the SOS requests is how they want it. Putting them inside Threads to keep things containerized was my idea. But I am interested in hearing more about your thoughts on this one. We are going to have to talk to SC C&S as well if we are going to change it.

[Goltred]

Ok, what about this... Do you think it might be good to have both versions? Someone could configure the bot to send these "upcoming operations" messages in a specific channel (e.g. you configure it in opsec-bot channel) and decide if they want a single dynamic embed, or to send the message in an interval (e.g. !opserv allops dynamic | !opserv allops schedule daily 19) That way people can decide how to use it... The channel where the message is received could be the one where the message will be sent, meaning that people could even set private notifications for it if they want to.

And if then you mix this up with the simpler embed you want to make (the one that notifies when an operation is created), then the whole op notifier becomes even more powerful because it gives power to the users. For this one, we could have opserv make a post request to the bot so that it knows that it needs to post a new operation, at which point the embed is focused on that one op. Later down the road, we could add an extra step here where the bot also posts the attendance link so that the op lead doesn't need to do it by hand, and even further down the road we could add interactions to this as well, so that people could for example subscribe to a private notification when the op is 30 minutes from starting

Well, if I recall correctly, the way they submit the SOS requests is how they want it. Putting them inside Threads to keep things containerized was my idea. But I am interested in hearing more about your thoughts on this one. We are going to have to talk to SC C&S as well if we are going to change it.

Not suggesting to change anything right now to be honest, if it works fine and they like it, then let's wait for people to ask for changes first? I was using it as an example only :) If the SOS bot is creating a thread to contain related discussions, i think that's fine and it makes a lot of sense. What I was thinking is that maybe we could add interactions to the original message to change the status of the request or something like that, but I haven't seen enough of these to make a really informed decision

[PatrickPedersen]

Ok, what about this... Do you think it might be good to have both versions? Someone could configure the bot to send these "upcoming operations" messages in a specific channel (e.g. you configure it in opsec-bot channel) and decide if they want a single dynamic embed, or to send the message in an interval (e.g. !opserv allops dynamic | !opserv allops schedule daily 19) That way people can decide how to use it... The channel where the message is received could be the one where the message will be sent, meaning that people could even set private notifications for it if they want to.

And if then you mix this up with the simpler embed you want to make (the one that notifies when an operation is created), then the whole op notifier becomes even more powerful because it gives power to the users. For this one, we could have opserv make a post request to the bot so that it knows that it needs to post a new operation, at which point the embed is focused on that one op. Later down the road, we could add an extra step here where the bot also posts the attendance link so that the op lead doesn't need to do it by hand, and even further down the road we could add interactions to this as well, so that people could for example subscribe to a private notification when the op is 30 minutes from starting

I am all for making both approaches. The more power they have the better. We just need to make sure that they know that they have that power 😄

Not suggesting to change anything right now to be honest, if it works fine and they like it, then let's wait for people to ask for changes first? I was using it as an example only :) If the SOS bot is creating a thread to contain related discussions, i think that's fine and it makes a lot of sense. What I was thinking is that maybe we could add interactions to the original message to change the status of the request or something like that, but I haven't seen enough of these to make a really informed decision

Yeah, let's leave it as is until they ask for it to be changed. If you have any ideas for changes to it tho, I would suggest talking to the SC C&S and see if they would be interested.