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.
Related
We make extensive use of push notifications in our Action for Google Assistant. Up until recently, we were able to use the notification id received from conv.argments.get('UPDATES_USER_ID') for new users and failing that we could conv.request.conversation.conversationId as an alternative.
If the user resets our Action on their Google Assistant, the original notification id is no longer valid. However, the notification id received for UPDATES_USER_ID post reset is generating an error "The caller does not have permission" with status "PERMISSION_DENIED". If we try to use the alternative, we get the error "Request contains an invalid argument" with status "INVALID_ARGUMENT".
We have been able to fix the issue by always relying on conv.request.conversation.conversationId as the push notification identifier for corresponding user. Although this entity's value changes with each user conversation, using the value supplied the first time seems to do the trick. Unfortunately, we could not find any documentation or community support on this.
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.
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?
After taking the user's permission to send push notifications and saving the userID in firestore, how can I use it to send notifications to them at a time of their choice daily ?
For example :
If the user selects 8:00 AM , I want to be able to send them the push notification everyday at 8 am.
I can't write the code to send the notification in the action itself.
What will I have to setup to accomplish this?
Once the user has granted you permission to send push notifications, you can use the Actions API to send the push notification.
The setup would be as follows.
Storing user preferences
1) Dialogflow agent asks the user when they want to be notified
2) User says they want to be notified at 8:00 am
3) Dialogflow detects the answer and makes a fulfillment request to your webhook (The webhook can be the inline editor in dialogflow (Functions) or another server)
4) In the handler of the intent, you have to store the UserId and the time they selected in your database (in this case, firestore)
5) Dialogflow agent gives the final answer to the user and the interaction ends
Sending the push notification
1) Identify if you have to send a notification to a user; this is the tricky part.
It is not possible to give you a definitive solution on this, because it heavily depends on the requirements of your system and the technologies that you are using/want to use.
Basically, you can use cron jobs, background infinite processes, pub/sub, cloud scheduler, or any other tool that allows you to constantly read information from your database to determine which users need to be notified. I recommend you to check this answer where is discussed an approach to tackle this problem using Firestore.
Notice that you don't necessarily need another server running, you can use the Functions used for the fulfillment.
For example. You can set up Cloud Scheduler to run each hour, and make a request to your Functions. In the request, you read from Firestore and extract the entities that need to be notified that hour.
2) Once you have the users that you want to notificate, you need to use the Actions API to send the push notification. Once again, this request can come from your fulfillment server, or another server used in the system.
I have deployed my api.ai bot with gupshup.io platform but the problem i am facing is that when i send a message through gupshup.io and check its response on heroku server, it sets all my parameter (which were supposed to be saved in context) as null.
While when i send the same message on api.ai, it works well (saves the values of variable in context).
I am unable to understand that why on gupshup.io, the api.ai bot is unable to send values of the variables during conversation.
Are you using the API.ai template on Gupshup.io? If yes, then this could be a problem due to the session ID which is unique for every message from the user. Hence every message is treated as a new message by api.ai
Check out the solution here in another thread -
Maintaining session in Gupshup bot calls to Api.ai
Do let me know if this helps.
it took me a bit to figure it out too but the trick is to have a unique ID but one which isn't unique all the time. In other words, there is 1 variable that is unique and at the same time never changes per user -> phone number.
You can use the phone number that is being passed (or sender id) and that will create unique sessions and at the same time, it will keep them persistent with the same person (so you don't lose context).