Add User Apps

[fgardt]

this is the implementation for user apps that I've been using like this since 3 days after user apps got announced / released to beta.

I like the flexibility that having install_context and interaction_context being separate properties brings but there were concerns regarding usability / it being too complex.

example:

#[poise::command(
    slash_command,
    install_context = "Guild|User",
    interaction_context = "Guild|BotDm|PrivateChannel"
)]
pub async fn info(ctx: Ctx<'_>) -> Result<(), CommandError> {
  // ...command impl...
}

note: this added the unstable_discord_api feature to the serenity dependency, that should probably be removed again(?) I have not found a nice way to feature guard this without having to chain the feature flag in everywhere and some other issues.

[GnomedDev]

I would recommend adding an unstable feature flag to poise, which enables the unstable_discord_api flag in serenity.

[C0D3-M4513R]

Also probably the docs should be updated with the new install_context and interaction_context options, if the unstable feature is enabled?

I can also confirm, that this pr works as expected, when using the current branch of serenity (as is expected).

[GnomedDev]

Hey, @fgardt do you plan on fixing the CI failures?

[fgardt]

I'll look into it yeah

[techs-sus]

hello, i've been testing this pr more in depth and subcommands work weirdly:

• the "parent" of the subcommands have full authority over interaction and install contexts
• the subcommands themselves cannot override the interaction context which results in interesting behavior

lets say you have a parent command: /bot and you want to make a "reload" command for the bot owner which reloads the bot

#[poise::command(
    slash_command,
    subcommands("reload"),
    install_context = "Guild|User",
    // hmm... only 1 command needs to be different; so lets do a non-restrictive selection
    interaction_context = "Guild|BotDm|PrivateChannel"
)]
pub async fn bot(_: Ctx<'_>) -> Result<(), CommandError> {}

#[poise::command(
    slash_command,
    owners_only,
    // great! now we can make this a botdm command to prevent confusion?
    install_context = "User",
    interaction_context = "BotDm"
)]
pub async fn reload(ctx: Ctx<'_>) -> Result<(), CommandError> {
  // ... reload logic
}

sadly, the subcommand has no control over its interaction_context or its install_context, which means the command will show up in guilds and in group dms, which is not the intended behavior

[jamesbt365]

Subcommands inherit context and permissions from the parent, this is a limitation of discord itself. At most extra documentation (if there isn't any of inheriting context) can be added, but its already mentioned for permissions in our docs.