Document role subscription system channel flags and message field #5828
Conversation
docs/resources/Channel.md
Outdated
| | ---------------------------- | --------- | --------------------------------------------------------------------- | | ||
| | role_subscription_listing_id | snowflake | the id of the sku and listing that the user is subscribed to | | ||
| | tier_name | string | the name of the tier that the user is subscribed to | | ||
| | total_months_subscribed | integer | the number of months that the user has been subscribed for | |
There was a problem hiding this comment.
If you want to be extra explicit, I would say cumulative number of months (vs consecutive)
| | position? | integer | A generally increasing integer (there may be gaps or duplicates) that represents the approximate position of the message in a thread, it can be used to estimate the relative position of the message in a thread in company with `total_message_sent` on parent thread | | ||
| | role_subscription_data? | [role subscription data](#DOCS_RESOURCES_CHANNEL/role-subscription-data-object) object | data of the role subscription purchase or renewal that prompted this ROLE_SUBSCRIPTION_PURCHASE message | |
There was a problem hiding this comment.
this is correct for now, we actually wanted to give it a generic name so that we can store any role subscription data on a message in one place. Right now we're using it to show the purchase recognition message but in the future, we might use this field to store some other role subscription message data.
We can update this in the future if we use it for something else though 👍
There was a problem hiding this comment.
If this were changed how would an application deal with it without crashing?
There was a problem hiding this comment.
The precedent for volatile internal fields is to prefix the name with _, similar to _trace in the READY dispatch.
There was a problem hiding this comment.
should I mark any of the fields as optional and/or nullable?
There was a problem hiding this comment.
If this were changed how would an application deal with it without crashing?
what I mean is that we might add new fields to that role_subscription_data for a new message type in the future and at that point, this field wouldn't be only used for the ROLE_SUBSCRIPTION_PURCHASE message type. we definitely won't change anything in the role_subscriptions_data for the ROLE_SUBSCRIPTION_PURCHASE type.
There was a problem hiding this comment.
if a field is not marked as optional then libraries would assume that the field will always be present in role_subscription_data, and might error if that is not true
There was a problem hiding this comment.
actually, seems like my memory is failing me, looks like we didn't mark any of those fields optional on the clientside so ignore my comments
* rename GuildFeature.CreatorMonetizableProvision to GuildFeature.CreatorMonetizableProvisional * deprecate GuildFeature.MonetizationEnabled, see discord/discord-api-docs#5724 (comment) * add @SerialName for DiscordRoleTags.botId * add RoleTags.isLinkedRole * fix DiscordMessage.roleSubscriptionData nullability * fix KDocs see discord/discord-api-docs#5724 and discord/discord-api-docs#5828
* rename GuildFeature.CreatorMonetizableProvision to GuildFeature.CreatorMonetizableProvisional * deprecate GuildFeature.MonetizationEnabled, see discord/discord-api-docs#5724 (comment) * add @SerialName for DiscordRoleTags.botId * add RoleTags.isLinkedRole * fix DiscordMessage.roleSubscriptionData nullability * fix KDocs see discord/discord-api-docs#5724 and discord/discord-api-docs#5828 Co-authored-by: NoComment <[email protected]>
…scord#5828) * Document role subscription system channel flags and message field * cumulative
I missed these in #5724
btw, thanks for using a proper object in the message field instead of abusing embed fields like automod (is that gonna be changed/is that format stabilized yet?)