Skip to content

Commit

Permalink
Add message interaction object change (#5140)
Browse files Browse the repository at this point in the history 
* Add change log for message interaction object change

* add disclaimer

* update doc
  • Loading branch information
@shaydewael
shaydewael authored Jul 1, 2022
1 parent 67c6001 commit 87d717b
Show file tree
Hide file tree
Showing 2 changed files with 35 additions and 7 deletions.
28 changes: 28 additions & 0 deletions docs/Change_Log.md
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,33 @@
# Change Log

## Add Subcommand Groups and Subcommands to Message Interaction Objects

> danger
> This entry includes breaking changes
#### July 1, 2022

While this is a breaking change, most apps only rely on interaction responses (for events `INTERACTION_CREATE` and `MESSAGE_CREATE`), *not* message interaction objects. [Interaction responses](#DOCS_INTERACTIONS_RECEIVING_AND_RESPONDING/message-interaction-object/interaction-object-interaction-data) are unaffected by this change.

#### Upcoming Changes

Starting **July 18, 2022**, the `name` field for [message interaction objects](#DOCS_INTERACTIONS_RECEIVING_AND_RESPONDING/message-interaction-object) will now include subcommands and subcommand groups in the value (along with the existing top-level command). In the future, we recommend not relying on this message interaction field.

The format of the value will be the different command levels (if they exist), separated by spaces:
`<command name> <subcommand group name> <subcommand name>`

The `name` field is only seen on messages that are a response to an interaction without an existing message, so interaction objects for message components don’t include this field.

#### Updating your app

Most apps only rely on interaction responses, not message interaction objects.

We don't recommend that your app relies on the `name` field for message interactions objects, but if it does you should update your app to handle subcommands and subcommand groups that your app may encounter.

As an example of the change, pretend your app had a command `/role` with subcommands `add` and `remove`. Currently, the `name` field in the original interaction payload would contain `role`. If you responded to that interaction with a message then fetched its contents, the `name` field for that message interaction object would contain `role` as well.

After this change, the `name` field for the original interaction payload will still contain `role`. However, now if you responded to that interaction with a message then fetched its contents, the `name` field for that message interaction object would contain `role add` or `role remove`.

## Changes to Bot Permissions for Interactions and Webhooks

> danger
Expand Down
14 changes: 7 additions & 7 deletions docs/interactions/Receiving_and_Responding.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -110,13 +110,13 @@ This is sent on the [message object](#DOCS_RESOURCES_CHANNEL/message-object) whe
###### Message Interaction Structure

| Name | Type | Description |
| ------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| id | snowflake | id of the interaction |
| type | [interaction type](#DOCS_INTERACTIONS_RECEIVING_AND_RESPONDING/interaction-object-interaction-type) | the type of interaction |
| name | string | the name of the [application command](#DOCS_INTERACTIONS_APPLICATION_COMMANDS/application-command-object-application-command-structure) |
| user | [user object](#DOCS_RESOURCES_USER/user-object) | the user who invoked the interaction |
| member? | [partial member](#DOCS_RESOURCES_GUILD/guild-member-object) object | the member who invoked the interaction in the guild |
| Name | Type | Description |
| ------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| id | snowflake | ID of the interaction |
| type | [interaction type](#DOCS_INTERACTIONS_RECEIVING_AND_RESPONDING/interaction-object-interaction-type) | Type of interaction |
| name | string | Name of the [application command](#DOCS_INTERACTIONS_APPLICATION_COMMANDS/application-command-object-application-command-structure), including subcommands and subcommand groups |
| user | [user object](#DOCS_RESOURCES_USER/user-object) | User who invoked the interaction |
| member? | [partial member](#DOCS_RESOURCES_GUILD/guild-member-object) object | Member who invoked the interaction in the guild |


## Interactions and Bot Users
Expand Down

1 comment on commit 87d717b

@ooliver1
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't recommend that your app relies on the name field for message interactions objects

Why is this? It is documented behaviour, it should not change before the next API version bump.

Please sign in to comment.