Feature: Include allowed mentions payload on message creation #1455
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change implements the AllowedMentions object for the payload of message creation. By default, the mentions behavior remains unchanged, the message content is parsed for all mentionable entities and they are all notified. If this payload is not null, it will use the content of the allowed_mentions field to determine if a role is notified, or just displayed. This change is interface breaking. This follows the conventions of keeping RequestOptions as the last argument, but could break some users who specify each of these arguments without using named arguments.
This change removes the commented-out code which was added during testing from the previous commit.
…ptions This change modifies the order of the AllowedMentions argument of SendMessageAsync so that this addition shouldn't be interface breaking. The downside to this change is that it breaks the convention followed by other methods, where the RequestOptions argument is normally last.
This change fixes a bug that was introduced while testing changes to the interface of the SendMessageAsync method to try and retain interface compatibility
…ally exclusive This change adds validation to SendMessageAsync which checks that the User flag is mutually exclusive with the list of UserIds, and that the Role flag is also mutually exclusive with the list of RoleIds
Adds read only properties which specify that all mentions or no mentions will notify users. These settings might be more common than others, so this would make them easier to use.
Still34
requested changes
May 5, 2020
|
Thanks for the detailed review @Still34 |
foxbot
approved these changes
May 7, 2020
SubZero0
pushed a commit
to SubZero0/Discord.Net
that referenced
this pull request
May 10, 2020
…d-net#1455) * Feature: Allowed mentions object on msg create (interface breaking) This change implements the AllowedMentions object for the payload of message creation. By default, the mentions behavior remains unchanged, the message content is parsed for all mentionable entities and they are all notified. If this payload is not null, it will use the content of the allowed_mentions field to determine if a role is notified, or just displayed. This change is interface breaking. This follows the conventions of keeping RequestOptions as the last argument, but could break some users who specify each of these arguments without using named arguments. * lint: remove commented-out code This change removes the commented-out code which was added during testing from the previous commit. * fix interface break: reorder allowedMentions arg so that it's after options This change modifies the order of the AllowedMentions argument of SendMessageAsync so that this addition shouldn't be interface breaking. The downside to this change is that it breaks the convention followed by other methods, where the RequestOptions argument is normally last. * docs: fix typo in allowedMentions arg doc * fix interface break arg from IRestMessageChannel * docs: update xmldoc for allowedMentions args * fix interface breaking arg order for ISocketMessageChannel * fix mocked classes that weren't updated * fix: RestDMChannel#SendMessageAsync bug, allowed mentions always null This change fixes a bug that was introduced while testing changes to the interface of the SendMessageAsync method to try and retain interface compatibility * docs: update xmldoc for AllowedMentions type * docs: reword xmldoc of AllowedMentionTypes type * docs: fix typo * fix: validate that User/Role flags and UserIds/RoleIds lists are mutually exclusive This change adds validation to SendMessageAsync which checks that the User flag is mutually exclusive with the list of UserIds, and that the Role flag is also mutually exclusive with the list of RoleIds * docs: reword summaries for AllowedMentions type * Add util properties for specifying all or no mentions Adds read only properties which specify that all mentions or no mentions will notify users. These settings might be more common than others, so this would make them easier to use. * docs: Resolve PR comments for documentation issues/typos
anonymousheadless
pushed a commit
to anonymousheadless/Discord.Net
that referenced
this pull request
Mar 29, 2021
…d-net#1455) * Feature: Allowed mentions object on msg create (interface breaking) This change implements the AllowedMentions object for the payload of message creation. By default, the mentions behavior remains unchanged, the message content is parsed for all mentionable entities and they are all notified. If this payload is not null, it will use the content of the allowed_mentions field to determine if a role is notified, or just displayed. This change is interface breaking. This follows the conventions of keeping RequestOptions as the last argument, but could break some users who specify each of these arguments without using named arguments. * lint: remove commented-out code This change removes the commented-out code which was added during testing from the previous commit. * fix interface break: reorder allowedMentions arg so that it's after options This change modifies the order of the AllowedMentions argument of SendMessageAsync so that this addition shouldn't be interface breaking. The downside to this change is that it breaks the convention followed by other methods, where the RequestOptions argument is normally last. * docs: fix typo in allowedMentions arg doc * fix interface break arg from IRestMessageChannel * docs: update xmldoc for allowedMentions args * fix interface breaking arg order for ISocketMessageChannel * fix mocked classes that weren't updated * fix: RestDMChannel#SendMessageAsync bug, allowed mentions always null This change fixes a bug that was introduced while testing changes to the interface of the SendMessageAsync method to try and retain interface compatibility * docs: update xmldoc for AllowedMentions type * docs: reword xmldoc of AllowedMentionTypes type * docs: fix typo * fix: validate that User/Role flags and UserIds/RoleIds lists are mutually exclusive This change adds validation to SendMessageAsync which checks that the User flag is mutually exclusive with the list of UserIds, and that the Role flag is also mutually exclusive with the list of RoleIds * docs: reword summaries for AllowedMentions type * Add util properties for specifying all or no mentions Adds read only properties which specify that all mentions or no mentions will notify users. These settings might be more common than others, so this would make them easier to use. * docs: Resolve PR comments for documentation issues/typos
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change implements the allowed mentions object for the payload of message creation, which allows for clients to specify which mentioned users and roles (including
@everyone) will be notified when the message is sent.The current version of this change is meant to be non-breaking to the SendMessageAsync interface, but it does not follow the pattern set by other methods where RequestOptions is the last optional parameter. Adding an overload didn't solve this issue as the interfaces became ambiguous.
TODO: