Why?

To allow more control over the server when an alert is triggered

What and How?

It'd allow for running commands as console when an alert is triggered.
Could be implemented pretty simply with the current alerts.yml like so

- Trigger: PlayerKickEvent
  Channel: general
  Conditions:
    - '#event.getPlayer().isBanned()'
  Embed:
    Color: "#ff0000"
    ThumbnailUrl: "https://cdn.discordapp.com/attachments/895784266976329739/979605823925919784/unknown.png"
    Author:
      ImageUrl: "{embedavatarurl}"
      Name: "🔨 Banned %cmi_user_nameplate_prefix%${#event.getPlayer().getDisplayName()}"
    Description: "**Reason:** ${#server.getBanList(T(org.bukkit.BanList.Type).NAME).getBanEntry(#event.getPlayer().name).getReason()}"
  Commands:
    - 'co rollback radius:#global time:1000d user:{#event.getPlayer().name}'

Are there alternatives?

ConditionalEvents can do this but it'd be nice to have it bundled with alerts

Checks

• I have used the search at least once to check if my idea has already been suggested and perhaps already implemented.

Anything else

No response

Running console commands via alerts seems quite out of scope for what alerts was initially intended for.

Though there is probably a decent amount of people who might want to do more with alerts than just send a message into a channel, and I feel expanding to a broader scripting API would serve as a better solution compared to just endlessly adding options to the current structure.

But that raises the problem that that kind of broader scripting API will be hard to get off the ground & implemented

Hi there.
To be clear, I fed him this idea.
As for my personal reason I have the following problem: As many server owners, I try to keep the amount of plugins installed as small as possible. I use cmi, which allows me to set a player's nametag, however it does so on join and never updates unless specified with other bukkit events such as death. Adding a new group to a user doesn't trigger updating it. A recursive task seems to be a bit overkill so my idea was to force an update when the appropriate luckperms event is fired. For this, I need to send the command.

Also, bored mentioned in the luckperms discord today that he had a problem: he wanted to give his staff bypass to the cmi auto-afk feature, which otherwise would ultimately expose a vanished staff with the broadcast. So he's using a third party plugin to add a group with this bypass permission to the user on vanish as, unlike essentials for example, his plugins do not offer an additional context which he could've used. If alerts had commands, he could use it to listen to the vanish enter event, added the group or permission with it via command, and removed it on vanish leave without needing another extra plugin.

Having thought about this for a few hours, it rang with me that basically, a command line here would be incredibly useful to somewhat imitate non existent contexts.
Here's another example: If, let's say you give a player the permission to use fly for a certain amount of time using luckperms 'settemp', users face the problem that the permission may run out, but the fly status isn't being toggled off, allowing them to fly, or for that matter, use whatever toggle-state permission (temp god etc) until they relog. This is such a nuisance, but nothing luckperms or any other permission manager is responsible for. Here, once again, we could listen to the node remove event, match the permission string to make sure it's the right one and toggle it off via command if it matches.

I agree that just adding and adding might not be the best idea. Perhaps this could be done as separate module instead. I've used conditional events a lot in the past, which is where I got this idea from. Sure it's no big deal about my issue with the tags, it's still annoying having to tell people to relog for this, or even worse, install an extra plugin as 'big' as conditional events juuuust for that. I'm not sure how much a module like this would actually drift away from the core idea about DiscordSRV as a whole.

@Vankka at first thought, I agreed with you that from an engineer's point of view having additional hooks/callbacks for triggers sounds bloating the main concept of the feature. However, after giving it a second thought, it's really a Minecraft console after all, it hasn't deviated from the eco-system DiscordSRV is dealing with. According to the snippet in OP, I abstract triggers as inputs and outputs; events coupled with optional conditions, and output embeds in specified channels. If we conceptualize embeds as a small step in the output, console commands start making more sense as complementary to that pipeline rather than just an additional "additive".

I support implementation but I'm not sure at which level it should be documented... if at all. I agree with Vankka that this isn't really something that alerts was originally intended for but I support allowing a bit more functionality for not much development effort.