I am trying to send an image to my Bot. This works in most versions of Skype, but for some reason it fails in the Windows 10 version of the Skype app.
The Bot is implemented and has been working for a while. It can be found by going to https://www.chtter.net and adding the Skype Bot.
When an image is sent to the Bot, the image is then downloaded to AWS S3, and then forwarded to the intended recipient of the image.
The problem is that when this is done using the "Classic" desktop version of Skype it works fine. If you send the image using the Android version of Skype, it works fine. But using the Windows 10 app, the Bot seems to throw an "Internal Server Error", and the file that is uploaded to S3 is not viewable. This doesn't seem to be an issue with the Bot code, since it works in many cases. It seems to be a difference between the Windows 10 app (or how it handles the Bot interface, or something) and other versions of Skype.
Has anyone else seen this, and is there some solution?
There are some known issues with the Skype Image Service right now (2017-12). Also, Skype does not maintain feature parity across their client app portfolio & unfortunately the Skype client differences can't be addressed from the bot-code side of things.
Related
We are facing issue in Azure chatbot, LUIS is not responding in Test in Web Chat on Azure. Chatbot is working fine Emulator and integration with direct line. My client is testing always from Azure so it is some critical issue for us. We are using Standard LUIS runtime subscription. It would be great if someone can help us. I did below trouble shooting steps.
Subscription key for standard plan and verify keys , it is correct.
Re-deployed
See application Insights error code is 400 only when i run it from Azure Test in Web Chat
I opened MS support ticket for this issue and find same issue was running at support team side as well. There were no code and configuration change after some time it suddenly start functioning.
Thanks
As the title mentions, I've got a question regarding the possibility of implementing the on send event functionality on the outlook PC client.
I current got an add-in running that blocks sending emails on the outlook WEB variant properly and allows sending them when the criteria is met. I've used the examples the microsoft documentation provides to get it to work. This example however doesn't work on the outlook PC (windows) client. Other functionality works just fine on the outlook PC client, it's just the on send not functioning. All I get on the outlook PC client is the error "[add-in name] couldn't complete. Please try sending this message later" upon pressing send.
Been looking at this for the past few days and based on all the microsoft documentation it gives me the impression that it should be possible, but I can't find any examples online or anyone really verifying it either. Which bring us to my question as I mentioned at the start;
Is it possible to make the outlook on send event work on the outlook PC client as well? And if so, does anyone have an example of how to do so?
Thanks in advance!
Yes, the on-send feature for Outlook add-ins is supported in certain versions of Outlook win-32. There is documentation here about which versions are supported and some code examples.
I managed to fix my issue.
So to recap; when running the nodejs server locally, the on send didn't appear to work for the outlook pc client. (It did for outlook web)
What I did was put the code on an external server and ran the nodejs. Then I created an IIS website with https and redirecred it towards the localhost port of the nodejs server.
After doing this and installing the manifest through the URL the issue no longer persisted for the pc client and worked exactly the same as the outlook web variant.
I am new, so I cannot add comments - but keep in mind that if you plan to put your add-in into AppSource - the doc says it will be banned: you are not allowed to use the OnSend event for anything in there.
I hope this helps you avoid some pain if you had those plans!
" Important. Add-ins that use the on-send feature aren't allowed in AppSource. "
( https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/outlook-on-send-addins?tabs=classic )
I have:
The corresponding Web-App running on localhost.
An open channel for MS Teams active within the Bot Framework, which displays 'running' all the time (no issues).
downloaded a VS19 project from git with a few pre-set bot-commands.
However, when I host the app via ngrok and try to contact the bot via teams the dropdown menu with the commands is diplayed, but the the bot replies to none of them.
When using the Bot Emulator, it also does not react to any messages (see below).
You said:
hello
Restart conversation from here
You said:
help
Restart conversation from here
Connectivity Status: Connected
Suggested Actions Container: Is empty
[10:03:51]Connecting to bot on https://localhost:3979/api/messages
[10:03:51]Emulator listening on http://[::]:58187
[10:03:52]-> conversationUpdate
[10:03:52]ngrok listening on https://67fe6eb30077.ngrok.io
[10:03:52]ngrok traffic inspector:http://127.0.0.1:4040
[10:03:52]Will bypass ngrok for local addresses
[10:03:52]POST400directline/conversations/<conversationId>/activities
[10:03:58]-> message hello
Since i was unable to resolve the issue I started the registration process over, this times with our tenants account. It didn't change very much except for causing an AADSTS700016-Error server side. After some research I stumbled accross this article, which explains the issue but also shows the solution, namely setting "signInAudience": "AzureADandPersonalMicrosoftAccount" in the registration manifest. This option was not available for my app for some reason so I set it to "signInAudience": "AzureADMultipleOrgs", which resolved the issue for now.
I am following this guide to develop chatbot:
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-howto-v4-luis?view=azure-bot-service-4.0&tabs=csharp#test-the-bot
When I tried to test the bot with Bot Framework Emulator, I am unable to get a response.
[15:17:43]Emulator listening on http://[::]:60595
[15:17:43]ngrok not configured (only needed when connecting to remotely hosted bots)
[15:17:43]Connecting to bots hosted remotely
[15:17:43]Edit ngrok settings
[15:17:43]-> conversationUpdate
[15:17:44]POST500directline/conversations/<conversationId>/activities
[15:17:51]-> messagehi
[15:17:51]POST500directline/conversations/<conversationId>/activities
Is this have to do with my company security blocking ngrok?
My Echo bot works fine, but seems like I am having issue with the LUIS function. Is there a way to make it work and link it to MS teams?
Help needed
WhatsApp just announced a new web application see here.
For some reason, the interface requires the phone to be connected all the time. Is it for performance reasons (not to create additional load on their current servers)? Is there any other constraint that cause that?
The official explanation:
Your session on WhatsApp Web is an extension of WhatsApp on your
phone. WhatsApp Web connects to your phone to sync messages, thus you
can see all messages on both devices. Thus, the first requirement to
being able to use WhatsApp Web is an active WhatsApp account on your
smartphone.
Source: https://www.whatsapp.com/faq/en/web/28080002
As you may know your Whatsapp history is only being stored in a database on the phone itself. To see that history in your web browser, it needs to get it from the phone. Whatsapp could have redesigned it, so that everything is stored in the cloud (as many competing messaging apps do). But that seems to be against their philosophy. They keep it tighly coupled to a (one) phone. As you may know you cannot install Whatsapp on multiple phones using the same account. The web interface is just a remote for Whatsapp running on your phone.
And even though I don't know for sure, I think it's more secure too. It wouldn't surprise me if the data that's sent between the web app and the phone is encrypted in a way that even Whatsapp themselves cannot decrypt. Maybe the QR code is generated client-side (in the browser) and by scanning it using the app there is no need to exchange the keys through Whatsapp's servers. That way they don't ever get the encryption keys and will not be able to inspect the data that gets routed through their servers.
Note: Of course Whatsapp could at any time change their implementation of both the app or the web app and enable eavesdropping.