I've got a GSuite add-on, which is privately available for our GSuite organisation. It works as intended on desktop, but somehow I'm unable to get it to show up on the Gmail (iOS) app like our domain-wide installed "Slack for Gmail" does. I've tried:
Finding out if I need special properties in my appscripts.json, nothing to be found about this.
Instead of installing it as a individual app, install it domain-wide (like our Slack app). No results.
Only thing I can think of that would be an issue is that our app is a organisational private app. Might that be the problem? I'm lost...
Unfortunately, only enterprise-level organizations (with well established and trusted platforms - who probably have special agreements with both Google and Apple) are able to deploy their add-ons so that they are accessible via iOS.
The rest of us are bound by a number of restrictions (with very limited mobile support for GSuite add-ons). See documentation.
Maybe the heads of your company can approach Google and/or Apple directly to work something out.
Related
I have a web app to be listed in the google workspace marketplace. I have a list of scopes that is needed to solve my use case. I have the dev version as a private app which uses the service account, tested all the functionalities and made sure everything is working fine.
Now how do I test how the flow is going to look like for the public app? I understand if someone from my own domain installs the app, I will be able to get the data but the public flow through the service account is still unclear for me.
You can test your add-on with a limited list of defined external users.
To do that, you must set the User type as External > Testing within the Oauth consent screen settings in Google Cloud Console.
Keep in mind that only the users defined in the settings will be able to test the app however.
You may find more information here and here
I have a Chrome extension that uses the Gmail REST API to send emails on behalf of the user. This API requires an Oauth2 token, which I'm retrieving using chrome.identity.getAuthToken.
The Problem
However, I am running into some issues with the Chrome Identity API. In particular, if the user authenticates with chrome.identity with a different Gmail account then the one they're signed into Chrome with, then they are prompted to re-login every hour or so (which doesn't happen if the accounts are the same). In addition, I'd like to minimize the number of permissions my extension asks for as a general principle (permissions sometimes introduce warning messages on install and risk disabling existing users on update), so I'd like to not have to ask for the "identity" permission if I can avoid it.
My Question
How can I authenticate the Gmail API in Chrome Extensions without using the Identity API?
Current Progress
I initially tried using Google's Javascript Client for auth, but that seems to be incompatible with Chrome extensions. After having searched other SO issues and some Google materials, it seems that the Identity API is indeed the recommended auth solution in Chrome Extensions. However, for the UX reasons mentioned above, I'm finding this solution problematic. And I do think an alternative should be possible -- for example, the MixMax Chrome extension, which uses the Gmail API, does not ask for the Identity permission.
Any help would be much appreciated! Thanks!
My Google App Script (an add-on for Google Docs) has passed the OAuth verification and has also been verified by the Google team. The application is both "Published" and "GAM: Published", yet Domain Admins are unable to locate the add-on when searching for it, and therefore cannot install it to their domain users.
I have read the following two articles many times:
https://developers.google.com/gsuite/add-ons/how-tos/publish-addons
https://developers.google.com/gsuite/add-ons/how-tos/publish-for-domains
I've been liaising with the docs-addon-advisor, who has approved the add-on again and again, but nothing seems to impact the Marketplace Apps search results. It is however availble in the Web Store search results. They have directed me back to this forum for advice.
I've followed the articles above and see no error messages in the publication, yet still the add-on remains invisible to the Domain Admin world.
You can see that DocuSign is happily installed in my domain, I can search for it, and it has been pushed down onto my domain users. So what I'm trying to achieve is possible. My add-on is simply absent from this marketplace search for some reason.
Any ideas?
Your add-on is published at https://gsuite.google.com/marketplace/app/seal_atn/820114923602. It does not have "Enable individual install" checked so it's installable and searchable only by domain admins.
I want to develop a comercial App that works in connection with gmail, Google calendar and other Google products. For what I see, Google Apps Script would give me the required functionality but I cant seem to find the answer to a couple of deployment issues. In the Google Apps Marketplace article on Wikipedia I read this:
Google Apps Marketplace is a product of Google Inc. It is an online store designed to help people and organizations to discover, purchase, and deploy integrated cloud web applications that work with Google Apps (Gmail, Google Docs, Google Sites, Google Calendar, Google Contacts, etc.) and with third party software. Some apps are free, some are paid for. Apps are based on Google APIs or on Google Apps Script.
But then, looking into the Google Apps documentation, the only distribution mechanisms I find are the "Script Gallery" which implies access to the source code by the end user and no comercial transaction or Chrome Web Store which is bound to Chrome Browser, while what I intend to do is aimed at Google Sites or Google Apps users and perfectly Browser Agnostic. My questions are:
Can I bundle a Google Apps Script based App for sell in the Google Apps Marketplace ?
Can I deploy it without the end users having access to the source code?
The short answer is no. Google Apps Script imposes daily quotas on all of their GAS APIs. These quotas cannot be extended in any way, so it is not feasible to deploy this on a commercial scale. You should take a look at Google Apps Engine which gives much more flexibility for what you want to do.
There is a workaround that I did in the past. I had an installation script (that ran as me) that collected user properties and the actual app script that ran as the individual user and referenced the user properties collected. At the time I didn't set user script properties but you could do that to bypass the first install script I would think. When the user installed they would get an email with the user script link and then they would authorize it separately. Install link was distributed through Google Checkout (deprecated now) but you could do electronic distribution through another venue. Not a traditional app distribution process by any means but maybe it will spark an idea for your specific case.
#Javier - we too arrived at the same conclusion. Google Apps Marketplace (GAM) deployment is just one of the channels to reach businesses but its the un-extendable Google Apps quotas that cripples a commercial deployment of a Google Apps Scripts (GAS) based WebApp.
We tried listing our webapp based on GAS directly into GAM but it failed their SSO requirements as there was no way to use domain-wide delegation to authorize the GAS permissions for the end users if the webapp ran as "user accessing the web app".
While we migrate to a fully stand-alone application, we have managed to deploy a restricted version of the app to GAM indirectly using a GAE instance as a proxy.
Here is how its deployed.
The GAM listing links to a GAE proxy app.
GAE proxy does GAM compliant SSO and redirects all subsequent access to our publicly accessible webapp in "run as me" mode.
GAE proxy passes on any domain data authorized by the GAM client to the webapp.
Implement security mechanism to block unauthorized access to the public webapp and accept calls ONLY from the GAE proxy.
Our current customers (very small businesses/startups) are fine with this security model, but I am afraid this will not scale for larger commercial deployment.
#mrschwen: we too are considering your exactly approach in mind to mitigate quota issues in case our app gets wider adoption until we are forced to move out of the GAS space, even though the end users will be forced to authorize our scripts which will run as 'user accessing the web app'
I have a nifty Google Apps Script app that I have developed. I would now like to port it to work on Android smart phones. Is there any suggested migration route to do this?
I know that Google Apps Script is already based on Google Web Toolkit, does that mean that I can use the same GUI widgets? For example the a vertical panel?
Thank You,
Commet
Do you mean installable Android Apps. If so, I have not come across yet anything which can port you GAS code to Android Apps.
If you mean a web application, You can access you published apps script application on your android phone via service URL using your android browser.
As Waqar mentioned, the best way is to have your GAS UI open up in the browser. And yes, Henrique is also right - not all UI elements are touch friendly.
Please also see an issue open for this - http://code.google.com/p/google-apps-script-issues/issues/detail?id=1092