You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Either orientation of the decorator should apply the allowed_installs setting to the hybrid command.
Actual Results
Only cases where the allowed_installs decorator runs first (ie, is lower in the decorator list) actually cause the decorator to work.
Intents
discord.Intents.all()
System Information
Python v3.8.5-final
discord.py v2.4.0-final
aiohttp v3.9.5
system info: Windows 10 10.0.19041
Checklist
I have searched the open issues for duplicates.
I have shown the entire traceback, if possible.
I have removed my token from display, if visible.
Additional Context
Also tested with app_commands.guild_only, which has the same issue. I do not know the full scope of decorators affected by this issue, but I would imagine it is all non-check app command decorators.
In the decorator logic, the else case handles the currently working case, which is when the decorator is used while the object is still a function. Later, when the app command is initialized, it properly includes the allowed_installs setting.
For hybrid commands specifically, the object that is returned from @commands.hybrid_command is a commands.HybridCommand, which does not inherit from app_commands.Command. Only commands.HybridAppCommand inherits from app_commands.Command, which would require accessing the .app_command attribute of the HybridCommand.
A potential fix is to add a 3rd case to these decorators, which checks for HybridCommands and pulls out the .app_command. I am not familiar enough with the flow of information for app command internals to know if that would be a satisfactory solution.
The text was updated successfully, but these errors were encountered:
Where in the documentation for the decorator is it noted? The example has it in the "working" order, but only for an @app_commands.command() case, which is not order dependent. There is no note stating a required order, and no note about differences for hybrid_commands. The only note is regarding subcommands, which does not apply in this case.
Summary
The ordering of
@app_commands.allowed_installs
and@commands.hybrid_command
affects whether theallows_installs
decorator will apply.Reproduction Steps
bot.tree.get_command("beforecom").allowed_installs
is the expectedAppInstallationType
object with the flags appliedbot.tree.get_command("aftercom").allowed_installs
isNone
Minimal Reproducible Code
Expected Results
Either orientation of the decorator should apply the
allowed_installs
setting to the hybrid command.Actual Results
Only cases where the
allowed_installs
decorator runs first (ie, is lower in the decorator list) actually cause the decorator to work.Intents
discord.Intents.all()
System Information
Checklist
Additional Context
Also tested with
app_commands.guild_only
, which has the same issue. I do not know the full scope of decorators affected by this issue, but I would imagine it is all non-check
app command decorators.discord.py/discord/app_commands/commands.py
Lines 2806 to 2811 in 9806aeb
In the decorator logic, the
else
case handles the currently working case, which is when the decorator is used while the object is still a function. Later, when the app command is initialized, it properly includes theallowed_installs
setting.For hybrid commands specifically, the object that is returned from
@commands.hybrid_command
is acommands.HybridCommand
, which does not inherit fromapp_commands.Command
. Onlycommands.HybridAppCommand
inherits fromapp_commands.Command
, which would require accessing the.app_command
attribute of theHybridCommand
.A potential fix is to add a 3rd case to these decorators, which checks for
HybridCommand
s and pulls out the.app_command
. I am not familiar enough with the flow of information for app command internals to know if that would be a satisfactory solution.The text was updated successfully, but these errors were encountered: