Is there any option to save updated contact details provided by Rapportive to google contacts ?
Any greasemonkey script or Firefox plugins ?
I've never seen that sort of Greasemonkey script of Firefox plugin, but conceivably it would be doable to rig up something to that effect. It all depends on Rapportive's Terms of Service, however.
Programmatically, Rapportive doesn't currently offer an outbound API - they currently only offer a way to programmatically send info to them regarding contacts. So you'd have to go about it another way. Scraping the info that's displayed could be an option - but I'd do due diligence first & be sure to read their policies. They might prohibit that sort of thing (they're owned by LinkedIn, whose TOS are known to be very restrictive).
You could also accomplish this sort of thing using FullContact (disclosure - my company). Our Address Book app (in beta) adds photos, social profile links, titles, etc. - the same sort of data returned by Rapportive - to Google Contacts and syncs in real-time.
We don't use Rapportive's data - the data is all public social profile data, returned by our social profile APIs - but the Address Book should help you do exactly what you're looking to do.
Related
Questions regarding billing for Google API's or more specifically the places and maps Google API's.
We have an app which is part of a SAAS package. When clients use our Software we have maps and place's API built it, however we want to offset the cost of the bill using these API's to that particular client using the software.
Currently we have a single Google Project we created and enabled the API's on our own google account however this means we will foot the bill as its using our token.
Can clients somehow connect to our google project etc or do we simply need them to create their own google project and pass that token through? Is there a streamlined approach that covers this...
When we did for our multi tenant application we did create only one google project and billing was getting accumulated into a single account. We looked at what you're talked about but since google does not allow to bill separately without having separate google project. Google API billing works on google project id. We decided to bill our clients separately and handled all calls to Places API on a single google project.
Long story short - it was not easy to have our clients connect to our project without having them create their own google project we ended up with one google api project.
edit: also missed another important point - Google My Business API needed whitelisting for each project id so it was another reason to keep it as a single project
Passing the token to the application is a probably very bad idea and will result in a security risk for your client and their token if it is intercepted.
As a developer for the client they should create a token on their account and then they will be charged. They can then give it to you as the developer for use. This is however a gray area as technically you are not allowed to share your tokens with anyone TOC However i believe that client and developer relationship should be secure enough for sharing the token.
Ideally you should give the client the code they can then use their own token and run the application themselves.
For several years we've had a Google Site setup on a non-profit G-Suite domain. This site is used once a year for a conference we hold with about 200 deleagates. The site is used by delegates for some simple stuff like reading documents, but there is a much more complex part of it too.
I've used Google apps script to write a system where users can do voting, speaker queueing, elections, and a daily checkin/rollcall. How it looks to users is they goto a page, and they see a "Vote Yes", "Vote No", and "Abstain" button. These are embedded Google apps script applets on the Google site page. Similar for the speaker queue and other functions.
On the backend, when a user clicks "Yes" or "No", the script submits a Google form on their behalf, with that answer. The form is tied to a Google sheet. Originally we had it directly append a line to a google sheet, but found with 200 people voting at the same time, we ran into performance issues and limitations with Google sheets.
The script then does stuff like de-deuplicate the results (incase someone voted multiple times), tabulates the results, and displays the results. This is all done on another page on the site that the officers running the conference can see.
For speaker queue, users basically click a button to say "I want to speak", and their names get added to a google sheet. The officers running the conference then call them up when it's their turn to speak. Users can also click a button to see where they are in the queue, and they'll get a response on the page like "You are currently number 3 of 27 users in the queue". They can also click a different button to remove themselves from the queue.
With that all explained, we're looking at potentially switching away from Google Sites, and considering Microsoft Sharepoint Online. The reason for this is we're using "old" Google sites, which Google has said will be shutdown at some point. "New" google sites currently does not support any scripting or API's at all, so it's impossible to redo our site in that system currently. They say API's are coming, but no details on what will and won't be available.
We have access to a free non-profits domain on Office365 (E1 tier) which gives us sharepoint online, active directory online, and $5k for free Azure credits.
So I'm asking you all here if there is some similar system available with O365/Sharepoint online. I'd want to change where all the data is stored to an SQL database, as storing stuff in sheets isn't ideal from any viewpoint, it's just the best option we had at the time. Ideally, the code for this would all live in the cloud like it does with Google. If I have to write code in Visual studio and upload it then I'm OK with that, but for maintenance purposes it would be really nice to have it all stored in the cloud and not need to install a thick app to work on it.
Basically we need the ability for users to login to a sharepoint site with their o365 account (we issue them the account), be able to interact with the site to send and receive data from SQL (which is running in Azure on same domain).
Can anyone point me in the right direction? It seems much more complex on the MS side, with way more potential methods for doing it (Graph, Sharepoint Addons, etc).
A couple photos:
Thanks!
I would like to provide a no coding solution here. If we want to code, then we can use SharePoint Add-in to do almost everything, such as collect user input and display data.
I've used Google apps script to write a system where users can do voting, speaker queueing, elections, and a daily checkin/rollcall. How it looks to users is they goto a page, and they see a "Vote Yes", "Vote No", and "Abstain" button. These are embedded Google apps script applets on the Google site page. Similar for the speaker queue and other functions.
On the backend, when a user clicks "Yes" or "No", the script submits a Google form on their behalf, with that answer. The form is tied to a Google sheet. Originally we had it directly append a line to a google sheet, but found with 200 people voting at the same time, we ran into performance issues and limitations with Google sheets.
I think we can create a Microsoft Form or Microsoft PowerApps to get user response. And then Store the data to a SharePoint list.
The script then does stuff like de-deuplicate the results (incase someone voted multiple times), tabulates the results, and displays the results. This is all done on another page on the site that the officers running the conference can see.
We can use Microsoft Flow to process the data, such as remove duplicated data. On the other hand, we can display results in PowerApps.
For speaker queue, users basically click a button to say "I want to speak", and their names get added to a google sheet. The officers running the conference then call them up when it's their turn to speak. Users can also click a button to see where they are in the queue, and they'll get a response on the page like "You are currently number 3 of 27 users in the queue". They can also click a different button to remove themselves from the queue.
We can do it in PowerApps.
I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
How can I (as a vendor contracted to develop an app for an enterprise) publish an app to the Google Play Store on behalf of an enterprise?
They don't have a Google Play account set up but want the app to appear under their brand in the Google Play Store.
What's the correct technical (and legal) process I should follow to set up their account and give my own company access to publish on their behalf?
The bare minimum requirement that I am aware of is that your company should get a written consent from your client, authorizing your company to use their company's name, logo, brand, etc for the expressed purpose of being displayed in Google Play.
My company had done something similar, we publish branded apps for clients, though our company's name is used as the vendor name. One of those apps got removed because some zealous legal guy in one of our client companies found the app and, unaware of the cooperation between the companies, filed a complaint to Google. The app was reinstated without much fuzz after getting that guy to send another email to Google requesting the app to be reinstated, so it looks like Google doesn't have anything against this (assuming your client doesn't reside in a sanctioned country).
You can give them advance notice by providing legal documents via this link
https://support.google.com/googleplay/android-developer/answer/6320428
From the page itself...
The Google Play App Review team accepts advance notice about your
upcoming app or store listing publishing event.
We only accept advance notice in the following scenario(s):
You have written documentation proving that you have permission to use
a 3rd party's intellectual property in your app or store listing (e.g.
Brand names and logos, graphic assets, audio, etc.). You have gambling
or casino-style elements in your game, and need to provide your Korean
Game Rating and Administrative Committee (GRAC) rating certificate to
Google so your game can be distributed in Korea.
Lesson learn by one suspended app. Hope this will help others. If your app suspended for such reason you can also contact them via link in the suspension email.
When I go to pull the full name on a certain contact (getFullName()) my script doesn't return any thing. However, when I make a change to the name from within the Gmail Contacts interface, it then returns the name. If I undo the change, I don't get the name.
Any reasons to this? The contact is another account of mine that's tied to my G+ account.
This is a very interesting find. I was able to reproduce this with some of my contacts as well. It must have something to do with the where these contacts were imported from or how they were manually created.
However, I dug a bit deeper and I do not believe this is an Apps Script issue, but a Google Apps Contact API issue. I found this same issue directly interaction with the Google Contacts API documented here -
https://developers.google.com/google-apps/contacts/v3/
This might be the same issue tracked in their issue tracker as #3171.
Bit more of the technical details of what I tried to confirm this -
a. Go to the oAuth playground at - https://developers.google.com/oauthplayground
and authorize manually for the scope of https://www.google.com/m8/feeds.
Once you click authorize, the tool will make your login and then authorize the playground tool to read your contacts.
b. Now, click the "Exchange Authorization Tokens" button to grab the final token for further REST calls.
c. Set the Request URI to https://www.google.com/m8/feeds/contacts/default/full and hit "Send the Request". You should get the XML dump on the right. Copy and view it in your favorite XML editor and you should see the same behavior you are describing above where Fullname only returns after an edit. You can narrow this down to invididual contacts (and stare at smaller XML files) by passing in a contact ID in the URL format of https://www.google.com/m8/feeds/contacts/default/full/{contactId}