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

Added ability to set response type #13

Merged
merged 4 commits into from
Jan 8, 2020
Merged

Conversation

ajtatum
Copy link
Contributor

@ajtatum ajtatum commented Jan 6, 2020

Without .NET Standard 2.0 there really isn't a nice way to get a Display/Description attribute. So, here's an easy implementation without any further changes.

The response type defaults to ephemeral.

@ajtatum
Copy link
Contributor Author

ajtatum commented Jan 6, 2020

I made my changes in VS 2019. I believe you'll have to change your configuration in AppVeyor or make changes to the code I submitted.

@prjseal
Copy link
Owner

prjseal commented Jan 6, 2020

Excellent. Thank you for this. I’ll try it out later

@prjseal
Copy link
Owner

prjseal commented Jan 7, 2020

I've tried testing it like this but I don't see any response in the channel. Any ideas what I need to enter in the text to test it?

        [Test]
        public void Emoji_Icon_Example()
        {
            var client = new SbmClient(WebHookUrl);

            var message = new Message
            {
                Username = "Alien",
                Text = "/who",
                IconEmoji = Emoji.Alien
            };

            message.SetResponseType(ResponseType.in_channel);

            var response = client.Send(message);
            Assert.AreEqual("ok", response.Result);
        }

@ajtatum
Copy link
Contributor Author

ajtatum commented Jan 7, 2020

I'm not sure, I tested it with the following two tests and they both showed up. Note that using it in the tests, the result will be the same. However, the response is different in a live environment when you have a Slack Bot with Slash Commands. Here are my tests:

/// <summary>
///     This example shows you how you can send response via in_channel
/// </summary>
[Test]
public void Response_In_Channel()
{
    var client = new SbmClient(WebHookUrl);

    var message = new Message("This is an in_channel response type.");

    message.SetResponseType(ResponseType.in_channel);
    var response = client.Send(message);
    Assert.AreEqual("ok", response.Result);
}

/// <summary>
///     This example shows you how you can send response via ephemeral
/// </summary>
[Test]
public void Response_In_Ephemeral()
{
    var client = new SbmClient(WebHookUrl);

    var message = new Message("This is an ephemeral response type.");

    message.SetResponseType(ResponseType.ephemeral);
    var response = client.Send(message);
    Assert.AreEqual("ok", response.Result);
}

I've attached two files from the bot I'm working on (https://github.com/ajtatum/StanLeeBot).

This is an "in_channel" response (Here's an usage example)
Marvel-Ironman

This is an "ephemeral" response. (Here's an usage example)
StanLee-Help

So, the tests I wrote above show the messages, but they'll both appear as though they're in_channel because of the context, but they do appear when using an Incoming WebHook from Slack.

Prior to making this change, all my messages sent through my bot appeared as ephemeral, meaning that nobody else in the channel was able to see the response. Once I added in the ability to set the response type, as shown in my examples, SlackBotMessages sends the message how you want it to appear.

@ajtatum
Copy link
Contributor Author

ajtatum commented Jan 7, 2020

I went ahead and added the four unit tests in there (two for BasicTests and two for BasicTestsAsync).

@prjseal
Copy link
Owner

prjseal commented Jan 8, 2020

Makes sense to me, thanks for this. I'll merge it now and do a release this evening.

@prjseal prjseal merged commit ceeae91 into prjseal:master Jan 8, 2020
@prjseal
Copy link
Owner

prjseal commented Jan 8, 2020

Version 2.1.0 released. This includes the response type and i've upgraded the project to .net standard to pave the way for future development if needed. I'm happy with this response type how it is though, so no need to go back and use description attributes.

@prjseal
Copy link
Owner

prjseal commented Jan 8, 2020

Just waiting for NuGet to publish it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants