Update forum channel docs

[ajpalkovic]

I think I got everything but hard to say for sure :)

[advaith1]

the emoji id types should be “snowflake or number” or “snowflake or 0”

[Mehgugs]

what does "name of the unicode emoji" mean exactly?

[Lulalaby]

In channel flags 1<<4 is missing for GUILD_FORUM channels (Require at least one tag for post)

[ajpalkovic]

what does "name of the unicode emoji" mean exactly?

uh, I think it's like thumbs_up for example?
idk should be the same as other places, like welcome_channel.emoji_name for example

[ajpalkovic]

the emoji id types should be “snowflake or number” or “snowflake or 0”

why?

[advaith1]

Did some edits to the emoji fields

looks like:

• the emoji id and name fields are not optional
• emoji_id is 0 if a custom emoji or no emoji is set
• emoji_name is null (not an empty string) if a unicode emoji or no emoji is set

also emoji_name is not the name of a standard emoji, it is the actual emoji like emoji_name: "🅰️"

and in other emoji fields, for custom emojis, name is the name of the custom emoji; why is that not the case here?

[advaith1]

the emoji id types should be “snowflake or number” or “snowflake or 0”

why?

Snowflakes are documented to always be a string in the HTTP API, unless the request has incorrect data. 0 is returned as a number, not a string, so it does not fit the requirements of a snowflake field.

honestly, ideally this field should just be null not 0, as I mentioned earlier

edit: fixed link

[advaith1]

Is this field intended to work for text channels?

The Modify Channel docs says this field applies to text and forum channels, however it only shows on forum channels in the UI, and it doesn't seem to have an effect when set on a text or announcement channel.

[Tin]

It only applies to forum channel.

[advaith1]

Will the channel template field be documented?

[advaith1]

The Modify Channel params do not have to explicitly be marked as optional because that is already documented:

All JSON parameters are optional.

[Lulalaby]

Will the channel template field be documented?

Is it even in testing?
On the guilds I have access to play around with forum channels, this field can't be set (It gets ignored / 403)

[advaith1]

oh, i didn't know setting it got blocked

[MinnDevelopment]

Could this still be changed to be consistent with other emoji in the API?

"emoji": {
  "id": 123,
  "name": "chillin",
  "animated": true
}

[ajpalkovic]

Uh, not right now, I'm just documenting what's implemented, but feel free to file a feature request for it

[MinnDevelopment]

Done #5393

[MinnDevelopment]

Is this copied client-side or in the api?

[ajpalkovic]

looks like in the API

[MinnDevelopment]

Just in case it isn't already known, the audit log handling in the client can't handle tag updates on posts:

[ajpalkovic]

Will the channel template field be documented?

Nope

[ajpalkovic]

Did some edits to the emoji fields

looks like:

• the emoji id and name fields are not optional
• emoji_id is 0 if a custom emoji or no emoji is set
• emoji_name is null (not an empty string) if a unicode emoji or no emoji is set

also emoji_name is not the name of a standard emoji, it is the actual emoji like emoji_name: "🅰️"

and in other emoji fields, for custom emojis, name is the name of the custom emoji; why is that not the case here?

fyi, it'll return null instead of zero "soon"

[Rapptz]

The POST /channels/{channel_id}/tags, DELETE /channels/{channel_id}/tags/{tag_id}, and PUT /channels/{channel_id}/tags/{tag_id} routes are undocumented. Is this because we're not supposed to use them or because of an oversight?

[advaith1]

those routes are deprecated and were replaced with PATCHing the channel with the new tags array

[Mehgugs]

fyi, it'll return null instead of zero "soon"

given this PR is merged – and thus available for implementation – won't this be a breaking change?

[ooliver1]

fyi, it'll return null instead of zero "soon"

given this PR is merged – and thus available for implementation – won't this be a breaking change?

Ah yes, another "may change soon" after a merge.

[ajpalkovic]

The POST /channels/{channel_id}/tags, DELETE /channels/{channel_id}/tags/{tag_id}, and PUT /channels/{channel_id}/tags/{tag_id} routes are undocumented. Is this because we're not supposed to use them or because of an oversight?

Don't use them, we'll get rid of them in the future.
We added support for editing them via the patch channel endpoint, which in hindsight is a much better way to do it because it also allows for reordering tags, which the current APIs don't allow

[ajpalkovic]

Ah yes, another "may change soon" after a merge.

There's no need for the attitude.
This is a case of us listening and responding to y'alls feedback!

Before merging this PR a change was merged that switched it from emoji_id=0 to emoji_id=null.
It was just waiting on a deploy, which is why I said "soon", so that you knew it wasn't live right now.
I checked just now and it looks like it was deployed last night, so the docs match the API behavior now, crisis averted!

[Rapptz]

Preface: I don't consider this a breaking change per se, especially based off of your explanation.

However, the emoji_id field is not documented as nullable in the docs right now (it needs to be ?snowflake). Also when testing my implementation ~20 minutes ago I still received 0 instead of null.

[ajpalkovic]

Ok, I can update the docs for that
As for getting a zero back still, I bet if you grab the channel via the HTTP API it returns null and not zero, is that right?
If so it's just forum channels that are cached in memory on our end that haven't been reloaded yet, hmm

[Rapptz]

As for getting a zero back still, I bet if you grab the channel via the HTTP API it returns null and not zero, is that right?

Yup, that seems to be the case.

[ajpalkovic]

👍 Well "soon" will be a bit longer then :D
But they'll reload all the caches in the next week or two