What is a proper way to handle AdaptiveCard action on the client side using DirectLine? Should I build "value" for activity by hand?
If so, I realized that multi-select's value is handled in different way for different channels (BotFrameworkEmulator sends the values separated with commas while WebChat uses semicolons). Which format should I pick? Isn't this inconsistency a bug?
The Emulator is in a sense a form of WebChat. I don't think the inconsistency is a bug, but if you see WebChat in different places then it's likely to be different versions and may therefore have different behavior.
Fortunately your bot code is free to interpret the received values however you want it to. If your bot is likely to run on multiple channels then you may want to make your bot smart enough to account for multiple possible choice-separators. Otherwise you can just make sure your bot is looking for the right separator for the channel you want to run it on.
As far as I can tell commas are the more standard up-to-date separators, so it's probably best to go with those. But if you're making your own Direct Line client then it's ultimately up to you how you format the activities that your client sends to the bot.
I would say that the inconsistency is not a bug, it is just the way the data is sent back by different channels. Please remember, Adaptive cards are a fairly new concept of exchanging data between the user and the bot code. It is still going to take time how the values are rendered and posted by each channel to come to a common format. That being said, I would not over think this problem much.
The design pattern for the bot should always be made after fixing the channels that the bot will be published on. Once the channels are fixed then it would just be matter of coding to handle the various ways in which the post back data is sent back to the bot
Related
What we are trying to do
I am working on automation which posts messages to a Slack channel using Incoming Webhooks on a custom Slack App. The messages mentions people.
What works
We can send a message just fine, it has formatted content, and usernames are correctly resolved using the link-names flag.
What isn't working
The whole point of the notification is to inform a dynamic set of people about something they should care about. The set of people we tag varies hugely (think people who contributed to a pull request) and so not all possible recipients are in the channel these automated messages go to.
We assumed that given the usernames are being directly #-mentioned, they would be notified by Slack. However, two of the users we've tested with and #-mentioned confirm they never received a notification they had been tagged.
This is different to "human" behaviour, where if you #-mention someone in Slack, you get a little message reminding you that person isn't in this channel and offers to invite them or let them know.
As far as we can tell, sending the message programmatically is doing the equivalent of "Do nothing" in the picture above. I want to do either of the other two options, preferably "Let them know".
How can I notify people they've been mentioned? I've looked at all the API documentation and nothing discusses notifying users who aren't in the channel that they are mentioned.
This can't be an uncommon issue.... right?
Notes:
We aren't directly calling chat.postMessage, it's just the only documentation on link_names I could find to link to. We are using Incoming Webhooks, which has minimal documentation on the parameters - it seems to be the same as chat.postMessage.
We would prefer not to move off Incoming Webhooks, but we can do a custom integration with the API if we have to.
You need to invite the user to the channel first, using the Python client that's:
client.channels_invite(
channel=channel_id,
user=user_id
)
I'm wondering if it's possible to create a program that sends a scheduled message in a Microsoft Teams channel?
It would preferably be undetectable to be a bot and seem like a normal message. If this is possible, is it possible to put if and else conditions in the program: for example, someone says 'hello' then the program responds with 'hello'.
Thanks.
If you want the message to come as if it was sent by you, you'd need to use the Graph API, something like this. It seems like you don't want to appear to be from a system (e.g. from a bot), but if you don't mind that in the end, you can also look at Incoming Webhooks, which are easy to use and don't need Graph or a Bot.
So to help debug we even take it out of our code and put it on twilio portal that lets us test the API. When I send to most of our group everyone gets the text message, but when we send to someone with tmobile, the message says it's delivered on twilio logs, but the person never gets it.
If we test and send him an 'Hello world' message, he gets it, but when we test with out SMS
'XXXXXX wants to make plans with you on the HotSauce App. :tada::hot_pepper:
Get the app now to join in on the action. https://rts2t.app.goo.gl/FGYB'
The message doesn't get delivered. Maybe there's a whitelist for Tmobile we can get on?
FYI, we have a USA number and this is a USA person and we are on the paid version, not trial.
I've encountered the same issue working on another app, and unfortunately I do not think there's a conclusive single answer. Carriers intentionally keep their spam filtering techniques secret so that they cannot be gamed. From Twilio's support page on the topic:
There is no standard practice for carrier filtering across all carriers. For some, filtering can range from a simple static list of prohibited terms to advanced machine learning systems that work in real time. Regardless of the system, carriers keep their filtering systems closely guarded secrets. In turn, Twilio cannot say definitively how these systems work or why a particular message was filtered.
Note that not all carriers report errors to Twilio, so some messages may appear to go through even though they were not delivered. You may or may not see error 30007 in the Twilio console when a message is blocked.
I don't believe any type of universal white-list exists, and once a number has been black-listed by a carrier there is no easy process to have it white-listed. However, short-code numbers are generally less prone to getting spam filtered (though they are more expensive).
While there isn't any one thing you can do to guarantee delivery, there are several things you can try:
Make the language of the text message more conversational as opposed to promotional
Don't obscure the url with a link shortener
Don't over-use a single number by implementing something like Twilio co-pilot
Include clear opt-out instructions
Is it possible to test the bot using predefined conversations?
How exactly does session.gettext() look for strings across libraries? Is it possible to call the same answers from multiple libraries?
Does bot.dialog.cancelAction trigger in child dialogs as well? It didn’t always work for us - is it possible to combine this with IntentDialogs at all or do IntentDialogs always override any global triggers?
For Czech and Slovak, we always translate incoming messages to English and send them to LUIS; however, can we also send them untranslated to a Q&A maker knowledge base?
How do we translate outgoing messages to the correct language when we haven't got access to session in IMiddlewareMap.send?
I am creating a bot using MS Bot framework - NodeJs. The below information needs to be captured for logging (Using the bot.use method i.e. IMiddleware).
Receive:
a. UserId
b. UserInput (text)
c. ConversationId
Send:
1. Name of Intent or dialog name that handled this (that handled the user input text)
2. Bot output text
3. ConversationId
4. UserId
I am unable to get the required detail for the 'send'. Can anyone provide me some suggestions on this.
Thanks.
I believe your main struggle is to log the name of intent or dialog. You won't know it in your send middleware if you haven't captured it during the routing phase. Once the Bot Framework figured out where to send the incoming message, it just invokes that function.
These two articles may help you get what you want. Just recently I played with capturing the conversation's breadcrumbs and also logging a full transcript:
http://www.pveller.com/smarter-conversations-part-3-breadcrumbs/
http://www.pveller.com/smarter-conversations-part-4-transcript/
If you need to build a reliable capture engine, I would suggest that you didn't use the session.privateConversationData like I did and instead built your own storage/log infrastructure to push the events to. Just stream them out with a timestamp and conversationId and reconcile on the other end later. The asynchronous nature of everything the bot framework does internally will be haunting you along the way so that's why. Plus, once you scale out beyond testing on a few users and your bot spans multiple processes, you will be out of the single-threaded event loop.