Document permission splits for expressions and events

[advaith1]

hi im back

New permission flags:

• CREATE_GUILD_EXPRESSIONS: 1 << 43
• CREATE_EVENTS: 1 << 44

This PR:

• Updates the permissions table to include the new perms and edit the descriptions
• Updates the emoji and sticker endpoint permission info
• Updates the scheduled event permissions section to clarify it and reflect the permission updates
• Adds a changelog for the change

Warning
Bots currently still use the old permission system, unless they send a recent X-Super-Properties header. This PR does not reflect this fact and only documents the new system.
EDIT 8/13: this change seems to affect bots now
EDIT: this change was reverted for bots

Other notes:

• The client incorrectly allows you to create events if you have MANAGE_EVENTS but not CREATE_EVENTS, but the API rejects the request.
• For bots with CREATE_GUILD_EXPRESSIONS but not MANAGE_GUILD_EXPRESSIONS, the user field is always included in List Guild Emojis, List Guild Stickers, and Get Guild Sticker, but not in Get Guild Emoji. Ideally, the last endpoint is changed to be consistent with the others. This PR documents the current behavior.

resolves #6298

[valdotle]

Also, should #6260 be updated in order to reflect these changes or will you include the permission changes in whatever PR gets merged last or make an entirely new one?

[andretran]

Hey @advaith1

I was the engineer who worked on the permissions split. I'm going to address your notes to:

1. Patch the UI bug allowing you to go through the create event flow if you only have MANAGE_GUILD_EXPRESSIONS
2. Make the GET Guild Emoji endpoint consistent with the other endpoints.

I'll give you a re-review once these are both addressed and we update the docs.

[andretran]

@advaith1
Following up with you.

1. Should be fixed now
2. I'm not going to change the current API behavior because I think it's designed as intended.

However the behavior around fetching is slightly more complicated. To clarify, this is what happens:

• GET - List Guild Emojis

  • If bot, we return you a list of emojis uploaded by the bot (don't need to serialize user here since all the emojis should belong to the bot)

  • if not bot, we return you all guild emojis and serialize the user only if it belongs to you and you have create permissions OR we attach the user to all emojis if you have manage permissions

  • GET - Guild Emoji

    • We return you a specific guild emoji and serialize the user if it belongs you and you have create permissions OR you have manage permissions (regardless if you're a bot or not)

• Both GET List Guild stickers and GET Guild Sticker behavior similarly to GET Guild Emoji

[advaith1]

@andretran I'm confused, your comment doesn't describe how the API currently works or ever worked. The list emojis/stickers endpoints always returned all emojis/stickers, even ones created by other users, and bots rely on this behavior. There has never been separate behavior for bots on that endpoint AFAIK. The list endpoints have also always returned user objects as long as you have Manage Expressions.

Get Guild Emoji is still giving me responses inconsistent with the other 3 endpoints I mentioned.

[colinloretz]

Coming back around to this one -- far too late, thanks for the work on this @advaith1.

Confirmed that what you are seeing and how the API is doing is expected. Will get this merged.