We have integrated the NodeJs bot application with the bot framework for interacting with bot in the Microsoft teams.
Based on the user input we are sending the adaptive cards respectively. Currently user can get the adaptive card today and can update the card later that day or after few days.
Is there any way to make the card expire after specific amount of time which make the card disabled.
Thank You
I have an idea how you could do this, but just an fyi that I've not done exactly this before, so there's no guarantee it will work. Basically, you'd be combining the ability to Update a message like discussed here with sending (or in this case 'updating') a pro-active message - see more here on that.
Because this is an existing conversation with the user, you'll have access from any existing message the user sends to get the parameters you need to start your proactive conversation (you need serviceurl, conversationid, tenantid, etc.). Do note that you can send a proactive message from OUTSIDE your bot (the code can be hosted somewhere else, and doesn't need to actually live IN your bot, even though to the user it will appear as if a proactive message was sent from your bot). I mention this because you could have this "expire card" message live in a separate process to your bot.
In case if you are still looking for an answer, I recently tried this approach:
In the card's response data, I set the expiry date and so now when the user submits the card, you can validate the data in the response and then update the card accordingly.
I had to use this approach because we have a very high user base and updating the card for all users proactively took much longer.
Cons: The card will remain will remain active, unless and until the user takes some action on it.
First of all, no this is nothing that is already implemented anywhere and you completely have to build that yourself.
One way to do this is this:
You need to store the activity / message ID for all cards you send. If you have the ID, you can always at any time go back and update the message (ie update your card)
Now that said, what i would suggest is this:
Sent a card to the user and store the id
Store the ID together
with creation date and expiration date somewhere on your end
Have some scheduled process that scans for expired cards
If a card is expired, update the message with a new card saying "sorry this card is expired"
We did that for our MS Teams Bot and its working quite well this way.
Related
I am trying to design a real time in-app chat for social application using PubNub. I found that the best architecture to do so for one to one chat with PubNub is detailed in this article http://pubnub.github.io/pubnub-design-patterns/2015/03/05/Inbound-Channel-Pattern.html
now my next problem is I have to display the list of users in the chatting window, how can I sort this list with the users who have sent messages latest at the top and the ones who have not interacted for a long time in the bottom. if I start fetching message from the inbound channel, I will have to always traverse inbound channel to the beginning every time a user has logged in, this will be a resource expensive call and also is not feasible if we have large user base and heavy message volumes.
I will also be using PAM to control authorization of users to read / write on channels.
That is indeed a great blog entry!
If you are in hybrid mode, so you do use a replicate channel for History feeding anyway, then I would use that same channel and intercept it the content with a function and simply store in the channel Object the list of latest visitors ordered, by the latest showing first, you can even add any extra info you would like to it. Then, any time a user can access the Object values from a REST function to PubNub, so as to retrieve the "hybrid channel" associated Object values (stored earlier) and send that list that is always updated to the Chat user. This has an advantage: if you do not want to retrieve messages until a user taped on one of the contacts in the contact list to avoid pre-loading, then you would load no messages for any channel, except maybe the first user, but then its always less to load from History then all messages from all of the channels, and its always available, before fetched, so fastest.
As I read in the Google documentation “all contexts expire after 20 minutes of becoming active” (https://cloud.google.com/dialogflow/docs/contexts-input-output). What I was wondering is if there is a way to extend this limit. For example, if I store an mp3 playlist in my context so that I can play next audio at the end of the current one, if the duration of the current mp3 exceeds 20 minutes I lose the context and any information on the next mp3.
You need to setup 2 things:
Your own webhook server.
A DB of your preference (I chose MongoDB) to store user data identifyied by an unique chat id, and it can be retrieved diferently from each platform that you integrate your chatbot with.
For example: on facebook you can use the userID of the user that is having a conversation with your bot as uniqueID, on twilio you can use the phonenumber and on your own chat UI for web you can stablish your own ID (usually a timestamp) as a parameter of the request you send to Dialogflow and store it on the localStorage of the client browser. So the next time the user chats with your bot within that same browser, you can get his data by using this uniqueID.
For facebook you can get the userid by using:
agent.originalRequest.payload.data.sender.id
For twilio:
agent.originalRequest.payload.data.From
For web (it depends of the variable that you send to the API)
agent.originalRequest.payload.data.{variable}
Using this uniqueID you can create your own DB registry for each user, get, retrieve or store data and make your contexts stay forever.
PS: Let me know If I was clear, its 4:34 AM lol, I can comment on this to clear any doubts.
Peace!
Can someone please share the postman to fetch TEAM roster or user profile information. I am referring to https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/get-teams-context?tabs=json
The Url you need is this: [serviceUrl] + "/v3/conversations/{teamId}/members/"
and it is based on two variables: the "teamId" is obviously different per team. However, the first part of the address (called the ServiceUrl) can also vary between teams, based on where they might be hosted, and you need both.
It sounds like, from the link you sent, that you already have a bot? If so, your bot can retrieve both of these required parameters. One way is that, whenever a user sends a message to the bot, to get the ServiceUrl and TeamId that are sent in the incoming "activity" object that. However, if you want it even earlier than this (i.e. before a user even sends a message to the bot), have a look at the conversationUpdate event here which will fire right when the bot is first added to the conversation.
Does that help?
I am working on my push notifications to users and working through the documentation.
Following this walk through, I have set up a webhook to send a notification to a user, this notes a target.userId for the recipient. Question, what exact value is the referring to? Is this the userId I invent for a user, or is it something else?
Looking at userId documentation, it appears this has to be generated/maintained, and can go stale every 30 days of inactivity. Noted here
My concern is - users sending other users notifications. If the recipients userId has gone stale from what I've stored in my database, I assume the push notification will fail when trying to find that user by userId that expired? Is this the only way to target a user for a push notification? My assumption is yes based on this documentation - but it seems brittle - or unstable, since it rely's on an ID that can expire (unless i'm misunderstanding userId's).
Is what I've outlined above the correct way to think about push notifications from one user to another? I store the users ID in my database, and when a message is triggered ie: "tell JimBob that I'll be there at 11." i look through my DB to find JimBob and his saved userId, and then send JimBob the push Notification from MarySue.
I assume this also denotes that JimBob has to allow push notifications from the intent "receive_message".
In this case, you're misunderstanding the ID that is sent to you.
First - the UserID you reference is deprecated and scheduled to be removed later this year. And even when it wasn't deprecated, it would be unique and non-duplicated, so there was little chance of missends.
The ID that you need to use will be handed to you when the user approves the subscription. This will be in the arguments that are sent as part of the Intent where they approve it, and not with the request in general. When sent to you, you need to save this.
Suppose I have my extension installed on two computers, and I am logged into both with the same google account.
Will chrome.pushMessaging.getChannelId return the same value for both computers? Is there any way to request that each individual install gets its own channel? I cannot find this information readily available anywhere.
The question was asked here on Stack Overflow https://stackoverflow.com/questions/13235810/google-cloud-messaging-and-identity, but there is no answer given.
From what I observe, the Channel ID is unique to the user's account, not unique to the install. But I am not sure if this is intended behavior or I can count on this always being the case.
I really think the Channel ID is per application ID and will stay that way. Otherwise, think how complex it would be to send a message to, say, 100,000 installations of your app. You'd have to keep a file of 100,000 Channel IDs, and it would take a very long time to invoke the API 100,000 times, since the Channel ID is part of the API call to send a message.
Sorry... I was wrong. To quote https://developer.chrome.com/apps/cloudMessaging:
"The push messaging service returns a channel ID to the client; this ID is specifically linked to your app ID and to the user."
If a server needs to send messages to all the installations of an app, it needs to keep track of the channel IDs sent to the server by those applications, and send the message to those channel IDs.