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

fix: AllowedMentions and AllowedMentionTypes #1525

Merged
merged 4 commits into from
Jun 16, 2020

Conversation

SubZero0
Copy link
Member

@SubZero0 SubZero0 commented May 12, 2020

Summary

Currently the values for the flag enum AllowedMentionTypes aren't there, so they won't work as expected.

Changes

  • Changed member values
  • Added None as 0
  • Initialized UserIds and RoleIds lists

SubZero0 referenced this pull request May 12, 2020
* 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
@Joe4evr
Copy link
Contributor

Joe4evr commented May 12, 2020

public List<ulong> RoleIds { get; set; }
/// <summary>
/// Gets or sets the list of all user ids that will be mentioned.
/// This property is mutually exclusive with the <see cref="AllowedMentionTypes.Users"/>
/// flag of the <see cref="AllowedTypes"/> property. If the flag is set, the value of this property
/// must be <c>null</c> or empty.
/// </summary>
public List<ulong> UserIds { get; set; }

These lists should be given an initializer, that way the user could write, for example:

new AllowedMentions
{
    UserIds = {
        123456789123456789ul
    }
};

@SubZero0 SubZero0 changed the title fix: AllowedMentionTypes values fix: AllowedMentions and AllowedMentionTypes May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants