For certain users, the actions on google userStorage object lives only during sessions. When the next launch request comes, it disappears (it's not in the incoming json). I recreate it with a new user id - everything is fine during the session, then I lose the stored state because I have to generate a new user id. For most of the users it works fine.
Am I missing something in the device setup? Voice identification? We are using DialogFlow but I don't think it is relevant.
Have those users enabled the Web & Activity setting and the include chrome history setting in the activity center?
If these settings are not enabled the user storage won't persist to the next conversation and anything that you save will be lost.
Related
I have setup watch channels for the User resource via the Google Directory API to receive push notifications when the resource changes or is created.
When my app receives a notification, it reads the e-mail of the user which was changed/created, then calls the users.get endpoint of the Directory API to get the latest data for that user and finally updates my database with that data.
In most cases this flow works fine, but I've observed that every now and then when a new user is created, the response from the users.get endpoint does not include the orgUnitPath property. It's not set to null, it's not even there. However, if I hit the endpoint again a while later, the property is there.
Does anyone know why this happens?
I want to send web push notifications to registered users, are there any best practices on how to implement the cases when multiple users have access to the same device and one should not see the message of another user.
Thanks in advance.
A web push notification subscription is tied to the browser, not the device.
What you need to do is, map this id with your registered user when he logs in from a particular browser. Also, you need to remove the subscription id mapping with any other users in the system.
In the case of multiple users using the same browser, the above logic will make sure that at a time, a particular browser subscription id is linked only to a single user.
And when you want to send a notification to a registered user, you can retrieve all push subscription IDs linked to this user in your database, and trigger notifications to those subscription IDs.
And don't forget to unmap a subscription id when the user logs out from a browser. Otherwise, he will continue to receive all notifications even if he has logged out.
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
I want to sync google calendar with my app.
When user add some event in the Google calendar at that time, I want these new event in my node server response
Means live sync with google calendar.
I want something like listener that listen new event.
With Google Calendar API you can watch for changes to Events or CalendarList resources, see this and this. Basically you will need to create an endpoint on your server which will receive events/calendars update notifications. When notification arrives, request a calendars/events synchronization. To make the synchronization efficient, use incremental sync. Check this question also to see the algorithm.
You may check this Quickstart tutorial and node-google-calendar.
You need to create a service account if you don't have one. A public/private key pair is generated for the service account, which is created from the Google API console. Take note of the service account's email address and store the service account's json or P12 private key file in a location accessible to your application. Your application needs them to make authorized API calls. If a user wants to give access to his Google Calendar to your application, he must give specific permission for each of the calendars to the created Service Account using the supplied email address under the Google Calendar settings.
I'm implementing OneSignal website push notification for my website. For now I just want to enable push notifications for the registered users. I had expected that there would be some callback methods after the users clicks "Allow" or "Block", but there aren't any. I see that I have to work with OneSignal.isPushNotificationsEnabled() and OneSignal.push(["getIdsAvailablegetIdsAvailable",..]), but I'm not sure how everything is supposed to come together.
What I think I should do is every time a registered users is at the homepage to execute something like this:
if isPushNotificationsEnabled
OneSignal.push(["getIdsAvailablegetIdsAvailable",..])`
send_user_id_to_server_where_it_is_saved_in_the_database
else
OneSignal.push(["registerForPushNotifications"..])
end
One thing that bothers me is that if this code gets executed and the user clicks "Allow" it will not trigger any code and a notification will never get to my server that the user has actually allowed push notifications. I'll have to wait for the user to come back or refresh the page. Is this how it's supposed to work or am I missing something?
After chatting with the OneSignal support, they made available a new method
OneSignal.on('subscriptionChange', function (isSubscribed) {..}]);
which will fire when the subscription status of the user changes. Note that a complete and valid subscription is based on a couple of things: notification permission, whether there is a background worker active to fetch notifications, whether the web database to store the user ID and registration token information is intact, whether the user has manually opted out or not.
There is a separate method that is not in the documentation, that is just for checking the user permissions:
OneSignal.push(["getNotificationPermission", function(permissions) {..}]);
The permissions parameter can be "default", "granted" and "denied".