Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(GuildMember): Expose serverMute and serverDeaf fields #10407

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

RealAlphabet
Copy link

Please describe the changes this PR makes and why it should be merged:
According to the developer documentation, it is possible to find out whether a member has been muted or deafen by right-clicking. Even if the member is not connected in a voice call.

This is documented by the presence of the two fields in the GuildMember structure.

Additional information: Unfortunately it's still not possible to mute or unmute a member if the member is not present in a voice channel. I intend to create an issue on discord-api-docs about this.

Status and versioning classification:

  • Code changes have been tested against the Discord API, or there are no code changes
  • I know how to update typings and have done so, or typings don't need updating

…r, even if the member is not connected in a voice call.
Copy link

vercel bot commented Jul 22, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Skipped Deployments
Name Status Preview Comments Updated (UTC)
discord-js ⬜️ Ignored (Inspect) Visit Preview Aug 10, 2024 10:56am
discord-js-guide ⬜️ Ignored (Inspect) Visit Preview Aug 10, 2024 10:56am

@RealAlphabet RealAlphabet changed the title fix: Allow developers to get the mute and deaf voice status of a member (server mute or deaf). fix: Allow developers to get the mute and deaf voice status of a member. Jul 22, 2024
Copy link
Member

@almostSouji almostSouji left a comment

Choose a reason for hiding this comment

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

  1. the docs should state that this is about the server deaf/mute state (as opposed to personal mute/deaf, terminology in-client is "Server Muted"/"Server Deafened")
  2. the current implementation always shows false for the inner payload of interactions, as those seem to not receive the two fields. potentially making the field nullable could work (same as you need to explicitly fetch a user to receive their public flags)l though this might also be an upstream bug

@almostSouji almostSouji changed the title fix: Allow developers to get the mute and deaf voice status of a member. feat: expose mute and deaf fields on guild members Jul 24, 2024
@RealAlphabet RealAlphabet changed the title feat: expose mute and deaf fields on guild members feat: expose serverMute and serverDeaf fields on guild members Jul 24, 2024
@RealAlphabet RealAlphabet changed the title feat: expose serverMute and serverDeaf fields on guild members feat: expose serverMute and serverDeaf fields on GuildMember Jul 24, 2024
@RealAlphabet RealAlphabet changed the title feat: expose serverMute and serverDeaf fields on GuildMember feat(GuildMember): Expose serverMute and serverDeaf fields Jul 24, 2024
…r on the server and set the default value to ‘null’ if the state is unknown.
@RealAlphabet
Copy link
Author

  1. the docs should state that this is about the server deaf/mute state (as opposed to personal mute/deaf, terminology in-client is "Server Muted"/"Server Deafened")
  2. the current implementation always shows false for the inner payload of interactions, as those seem to not receive the two fields. potentially making the field nullable could work (same as you need to explicitly fetch a user to receive their public flags)l though this might also be an upstream bug

I've taken your suggestions on board. Thank you for taking the time to read my PR. I'd be grateful for feedback on the latest changes. I've taken the voiceStateUpdate event into account so that the voice state of a "previously disconnected" member reflects the two fields.

For your second point, it might definitely be an upstream bug. At least it should be documented by Discord.

@almostSouji
Copy link
Member

almostSouji commented Sep 5, 2024

Asking for clarification upstream: discord/discord-api-docs#7125
Putting this on hold since this influences how we may want to implement the feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Review in Progress
Development

Successfully merging this pull request may close these issues.

2 participants